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

[jsm at polyomino dot org dot uk]

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

On Fri, 27 Aug 2004, terra at gnome dot org wrote:

> http://www.caldera.com/developers/devspecs/abi386-4.pdf on page 32 makes it
> clear that "int x : 5" should have the range 0-31.  Sun's C compiler has the
> same idea on solaris.
> 
> The conform to the ABIs, -funsigned-bitfields therefore needs to be the default
> for i386 and sparc at least.

What is this to do with the ABI?  I.e., what is your argument against the 
section of the manual (in trouble.texi) explaining why this does not 
belong in an ABI?  The documentation of implementation-defined behavior in 
implement-c.texi specifically describes how GCC implements this and does 
not refer to an ABI.

I should also add that while as that document suggests we let 
-funsigned-bitfields determine the signedness of bit-fields declared as 
plain char, short, long (or long long), which accords with the handling of 
this matter in C++, I see nothing in the C standard that would permit 
doing so; it only refers to int for such special handling and short is 
always the same as signed short (for example).  Thus the only way we get 
away with doing so is that we document that we don't allow these types as 
implementation-defined extra bit-field types (pedwarning for them if 
pedantic).  If we were to change to allowing them in C99 mode as proper 
implementation-defined types, DRs would be needed about this and other 
issues.

Also, that document doesn't discuss _Bool, long long or complex types, 
i.e. it predates C99; a more recent version or supplement discussing C99 
is needed before we could completely resolve the lack of ABI documentation 
by saying "on platform X we follow that document", though we could still 
say "on platform X we follow that document for the features described 
therein, subject to these exceptions and these extensions".



-- 


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