This is the mail archive of the gcc-bugs@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]

[Bug target/17211] [sparc/i386]: Bitfields should be *unsigned* by default.


------- Additional Comments From jsm at polyomino dot org dot uk  2004-08-30 15:57 -------
Subject: Re:  [sparc/i386]: Bitfields should be *unsigned*
 by default.

On Mon, 30 Aug 2004, terra at gnome dot org wrote:

> Note, that the expection is for the *specifier* int, not the C-type int.
> Therefore "short int" etc. are perfectly covered by the very same clause.
> (I guess that leaves "char" if you really wanted to nit-pick about it.)

It is quite clear from the context that "specifier" refers one of the 
lists rather than to "int" on its own; your reading would make it 
implementation-defined whether "signed int" meant "signed signed int" or 
"signed unsigned int", both of which are invalid.  After all, "long int" 
has meaning as a whole; in it, "int" does not designate a type at all.

> Note, that the language laywers at Sun seem to have decided that the smaller
> types should be unsigned by default too.

What does their C99 compiler's documentation of implementation-defined 
behavior say about implementation-defined other bit-field types?

> The rant in trouble.texi is misguided.  The ABIs make lots of random choices
> for which one could write an almost identical rant.  (Bit-field packing;
> int alignment.)

Some rants in trouble.texi are misguided, but that one makes a specific 
decision about interoperability of GNU C on different platforms.  
Bit-field packing and int alignment affect interoperability of compiled 
objects in a way bit-field signedness doesn't; it is an API issue and we 
can fixinclude system headers making a particular presumption to state 
signedness explicitly.

GCC supports many variations of implementation-defined behavior on each 
platform, with options such as -funsigned-bitfields, -fshort-enums, 
-fshort-wchar.  Proper documentation of what behavior GCC has on each 
platform needs to take account of this.

We do not currently have much in the way of documentation that says "on 
platform X, GCC follows ABI Y subject to caveats and command-line 
influences Z".  This is indeed a bug.  Fixing it means ensuring 
documentation describing the actual ABI and API GCC follows rather than 
just pointing to a vaguely similar ABI and API for a given CPU.  The ABI 
and API GCC follows can be changed if necessary, but only with great care.  

Considerations in choice of interface include compatibility with previous 
versions of GCC, compatibility with other compilers on platforms where GCC 
is not the system compiler, efficiency of particular interfaces, and 
consistency and implementability of particular specifications.  The most 
natural choice in documentation is to document what GCC does, i.e. make 
clear GCC's choice for bit-fields, rather than artificially require GCC to 
follow an external ABI in this regard.  On x86-linux, where GCC is the 
system compiler, I don't think there can be much case for changing the 
rule for bit-field sign; GCC has determined the de facto API and ABI. Some 
platforms might sufficiently strongly define a particular C API that it 
makes sense to provide that by default rather than the normal GNU C API.  
Perhaps MCore is one such.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17211


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