This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/17211] [sparc/i386]: Bitfields should be *unsigned* by default.
- From: "jsm at polyomino dot org dot uk" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Aug 2004 15:57:57 -0000
- Subject: [Bug target/17211] [sparc/i386]: Bitfields should be *unsigned* by default.
- References: <20040827145141.17211.terra@gnome.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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