Re: Random C9X conformance notes

[Geoff Keating <geoffk at ozemail dot com dot au>]

> From: Joe Buck <jbuck@synopsys.com>
> Date: Thu, 12 Aug 99 10:39:30 PDT
> Cc: egcs@gcc.gnu.org
> 
> Geoff Keating quotes the gcc manual:
> 
> > >    * `-2147483648' is positive.
> > > 
> > >      This is because 2147483648 cannot fit in the type `int', so
> > >      (following the ANSI C rules) its data type is `unsigned long int'.
> > >      Negating this value yields 2147483648 again.
> 
> The manual is incorrect.  It should read
> 
> 	* `-2147483648' is positive for ports where `long' is 32 bits.
> 
> On the Alpha, it is negative.  In the early days, gcc had the 'all the
> world's a Vax' disease, so this statement was true without qualification.

Oh, I was just assuming "on a 32-bit machine" implicitly in the
documentation.  Probably that should be changed.

> Geoff again:
> 
> > If ANSI C really required this before, then this is a significant
> > quiet change and may go away before the final standard (I'm looking at
> > last August's draft).  It may not.  The draft does make it very clear
> > that decimal constants are always signed.
> 
> I don't see how C9X could drop this change.  If long long is a true type
> that is co-equal with other types, they have to do it this way.  In ANSI
> (ISO) C, if an integral constant doesn't fit in an int, we first see if it
> fits in a long, and finally try unsigned long.  In C9X, we try int, long,
> and finally long long.  This follows naturally if you say that long long
> is a real type (though one could add unsigned long long as a final type,
> it's arguably more natural to ask the user to give a U to get an unsigned
> literal).
> 
> One could argue that since GNU C supports long long, it should have been
> using the C9X semantics all along.
> 
> The change is less significant than it appears, because it's hard to
> write programs that don't use 'long long' where you can observe the
> difference.  That is, if you use -2147483648 to initialize a 32-bit
> value, you will get the same result for ANSI and C9X.

This is true, although it's not _that_ hard.  For instance,

printf("%lx\n", 2147483648);

> One possibility is for gcc to issue warnings for integral constants (that
> have no U or LL qualifier) that don't fit in a long, but that do fit in an
> unsigned long, since those are the constants that behave differently in
> ANSI and C9X, and even in ANSI may have surprising results.  The user
> can always eliminate the warning by adding an explicit U or LL.

We'd certainly want this, at least as an option.

-- 
Geoffrey Keating <geoffk@cygnus.com>