Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 74873 invoked by uid 500); 13 Apr 2000 16:50:34 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 74856 invoked from network); 13 Apr 2000 16:50:34 -0000 Date: Thu, 13 Apr 2000 09:50:32 -0700 (PDT) From: dean gaudet To: new-httpd@apache.org Subject: Re: cvs commit: apache-2.0/src/lib/apr/include apr_time.h In-Reply-To: Message-ID: X-comment: visit http://arctic.org/~dean/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On Wed, 12 Apr 2000, Tony Finch wrote: > dgaudet@locus.apache.org wrote: > > --- apr_time.h 2000/03/31 08:35:56 1.14 > > +++ apr_time.h 2000/04/11 16:21:21 1.15 > > @@ -71,6 +71,12 @@ > > #ifdef WIN32 > > #define AP_USEC_PER_SEC ((LONGLONG) 1000000) > > #else > > +/* XXX: this is wrong -- the LL is only required if int64 is implemented as > > + * a long long, it could be just a long on some platforms. the C99 > > + * correct way of doing this is to use INT64_C(1000000) which comes > > + * from stdint.h. we'd probably be doing a Good Thing to check for > > + * INT64_C in autoconf... or otherwise define an AP_INT64_C(). -dean > > + */ > > #define AP_USEC_PER_SEC (1000000LL) > > #endif > > Why not just drop the suffix completely and let integer promotion do > the trick? 'cause it doesn't work... it works fine if you have a long long somewhere on the rhs, but if you're just using integer constants with no suffix they have type (int) and rollover on 32-bit boxes. i think the obscure reason for not using (long long)1000000 is when you use a box that isn't two's complement. but doesn't C99 enshrine the modern cpu anyhow? so maybe this is moot. but it's odd they'd go to the effort of defining the INTn_C() macros if there weren't a reason for it. -dean % cat t.c void foo(long long *ick) { *ick = 1000000*1000000; } void bar(long long *ick) { *ick = 1000000*1000000LL; } % gcc -c -S t.c t.c: In function `foo': t.c:3: warning: integer overflow in expression % cat t.s .file "t.c" .version "01.01" gcc2_compiled.: .text .align 4 .globl foo .type foo,@function foo: pushl %ebp movl %esp,%ebp movl 8(%ebp),%eax movl $-727379968,(%eax) movl $-1,4(%eax) .L1: leave ret .Lfe1: .size foo,.Lfe1-foo .align 4 .globl bar .type bar,@function bar: pushl %ebp movl %esp,%ebp movl 8(%ebp),%eax movl $-727379968,(%eax) movl $232,4(%eax) .L2: leave ret .Lfe2: .size bar,.Lfe2-bar .ident "GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)"