This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Kill traditional mode


On Wed, 27 Feb 2002, Zack Weinberg wrote:

>  This is because 2147483648 cannot fit in the type @code{int}, so
> -(following the ISO C rules) its data type is @code{unsigned long int}.
> -Negating this value yields 2147483648 again.
> -
> -@item
> -GCC does not substitute macro arguments when they appear inside of
> -string constants.  For example, the following macro in GCC
> -
> -@example
> -#define foo(a) "a"
> -@end example
> +(following the ISO C rules) its data type is @code{unsigned int}.
> +Negating an unsigned 2147483648 yields 2147483648 again.

That's an incorrect change; decimal constants in C90 go int, long,
unsigned long.

> -@cindex structures
> -@cindex unions
> -@item
> -When compiling functions that return structures or unions, GCC
> -output code normally uses a method different from that used on most
> -versions of Unix.  As a result, code compiled with GCC cannot call
> -a structure-returning function compiled with PCC, and vice versa.

Make sure this information is duplicated in interface.texi before removing
it.  (Though we really need updates for the ABI compatibility docs, making
clear on exactly what systems we are / are not compatible with what other
compilers under what circumstances, what is relevant to current systems
and what to old systems.)

> -@cindex preprocessing tokens
> -@cindex preprocessing numbers
> -@item
> -GCC complains about program fragments such as @samp{0x74ae-0x4000}

This issue still confuses users (who aren't generally familiar with the
concept of preprocessing numbers).

-- 
Joseph S. Myers
jsm28@cam.ac.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]