Jeffrey A Law law@cygnus.com
Mon Jun 7 19:19:00 GMT 1999

  In message < 19990604094348B.mitchell@codesourcery.com >you write:
  >  Jeff's statements reflect a policy change relative to what has been
  > in the manual for quite some time, at least with respect to the
  > particular issue of bitfields.
The problem is the documentation is wrong about whether or not the signedness
of a bitfield matters between .o files.  I have no idea who wrote this
paragraph, but it is absolutely wrong:

  Some computer manufacturers have published Application Binary Interface
  standards which specify that plain bitfields should be unsigned.  It is
  a mistake, however, to say anything about this issue in an ABI.  This is
  because the handling of plain bitfields distinguishes two dialects of C.
  Both dialects are meaningful on every type of machine.  Whether a
  particular object file was compiled using signed bitfields or unsigned
  is of no concern to other object files, even if they access the same
  bitfields in the same data structures.

If the signedness of a bitfield did not matter as the person who wrote this
paragraph suggests, then I would agree that we need not concern ourselves
with this issue.

But the reality of the matter is the signedness of a bitfield is important from
an ABI standpoint.

Consider the following test

struct x
  int bitfield : 10;


#include "foo.h"
struct x x;
main ()
  x.bitfield = 0x200;

  printit (x.bitfield);

printit (int num)
printf("%d\n", num);

#include "foo.h"
extern struct x x;

  printit (x.bitfield);

If foo.c and bar.c are compiled with different signedness of bitfields they
will pass different values to printit.  One will pass 0xfffffe00 and other
0x200.  Clearly different and can cause a variety of problems is you're not

This situation is not unlike the structure return nonsense that we finally
got RMS to agree to fix a few years ago.  In short RMS claimed that gcc should
not worry about compatibility with system compilers for structure returns
because gcc's scheme was superior (and it was superior).  The problem with that
claim was the ABI incompatibility caused numerous problems when interfacing
with objects built with the system compiler).  That is totally losing behavior.
We're in basically the same boat here.

Introducing ABI incompatibilities on a silly and misguided principle that
the signedness of a bitfield should not be defined by an ABI is rather
dumb and short-sighted.

  > I believe that GCC has always tried to handle structure layout
  > compatibly, and so forth, so that user code could be linked to native
  > libraries.   However, the bitfield issue was clearly documented as
  > *not* following the native conventions.
That's because the author of that passage is clueless in regards to the
effect of bitfield signedness.

One of the things we need to do with egcs is fix the absolutely stupid stuff
that went in because someone thought they knew about designing compilers, but
really didn't have a clue.


More information about the Gcc-patches mailing list