Random C9X conformance notes

Random C9X conformance notes

[Geoff Keating]

Here are some things that also need to be looked at for C9X
conformance:

> Standard Libraries
> ==================
> 
>    GCC by itself attempts to be what the ISO/ANSI C standard calls a
> "conforming freestanding implementation".  This means all ANSI C
> language features are available, as well as the contents of `float.h',
> `limits.h', `stdarg.h', and `stddef.h'.
...

In C9X, there are also iso646.h, stdbool.h, and stdint.h, of which gcc
does provide the first two.

There seems to be no particular reason why gcc shouldn't provide
stdint.h also.  In fact, since it's compiler-specific, it would
probably be a good idea to override the system's one; you don't want
intmax_t referring to some type longer than (this version of) gcc
supports.

>    * `-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.

In C9X, -2147483648 is negative, because 2147483648 has type 'long
long'.  -0x80000000 is still positive.  -2147483648u is also still
positive.

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.

-- 
Geoffrey Keating <geoffk@cygnus.com>

Re: Random C9X conformance notes

[Joe Buck]

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.

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.

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.

Re: Random C9X conformance notes

[Geoff Keating]

> 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>

Re: Random C9X conformance notes

[Geoff Keating]

> 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>

Re: Random C9X conformance notes

[Joe Buck]

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.

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.

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.

Random C9X conformance notes

[Geoff Keating]

Here are some things that also need to be looked at for C9X
conformance:

> Standard Libraries
> ==================
> 
>    GCC by itself attempts to be what the ISO/ANSI C standard calls a
> "conforming freestanding implementation".  This means all ANSI C
> language features are available, as well as the contents of `float.h',
> `limits.h', `stdarg.h', and `stddef.h'.
...

In C9X, there are also iso646.h, stdbool.h, and stdint.h, of which gcc
does provide the first two.

There seems to be no particular reason why gcc shouldn't provide
stdint.h also.  In fact, since it's compiler-specific, it would
probably be a good idea to override the system's one; you don't want
intmax_t referring to some type longer than (this version of) gcc
supports.

>    * `-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.

In C9X, -2147483648 is negative, because 2147483648 has type 'long
long'.  -0x80000000 is still positive.  -2147483648u is also still
positive.

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.

-- 
Geoffrey Keating <geoffk@cygnus.com>