Re: [PATCH] DEFAULT_SIGNED_BITFIELDS Macro

[Mark Mitchell <mark at codesourcery dot com>]

I don't think that this patch is in the spirit of GNU CC, as recorded
in the current manual.  We could decide to change the manual, but I
think it would be a not-insignificant change.  Before doing so, I
suggest that the steering committee think carefully about the
rationale for doing so, and debate the manual section quoted below.

I, for one, agree with the manual.  It is more important to the GNU
project, IMO, that programs be treated uniformly across machines, so
long as they are always compiled with GCC, than that we maintain
compatibility with the system C compiler.

See, in particular, the "Non-bugs" section:

Certain Changes We Don't Want to Make
=====================================

   This section lists changes that people frequently request, but which
we do not make because we think GNU CC is better without them.

   * Making bitfields unsigned by default on particular machines where
     "the ABI standard" says to do so.

     The ANSI C standard leaves it up to the implementation whether a
     bitfield declared plain `int' is signed or not.  This in effect
     creates two alternative dialects of C.

     The GNU C compiler supports both dialects; you can specify the
     signed dialect with `-fsigned-bitfields' and the unsigned dialect
     with `-funsigned-bitfields'.  However, this leaves open the
     question of which dialect to use by default.

     Currently, the preferred dialect makes plain bitfields signed,
     because this is simplest.  Since `int' is the same as `signed int'
     in every other context, it is cleanest for them to be the same in
     bitfields as well.

     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.

     A given program is written in one or the other of these two
     dialects.  The program stands a chance to work on most any machine
     if it is compiled with the proper dialect.  It is unlikely to work
     at all if compiled with the wrong dialect.

     Many users appreciate the GNU C compiler because it provides an
     environment that is uniform across machines.  These users would be
     inconvenienced if the compiler treated plain bitfields differently
     on certain machines.

     Occasionally users write programs intended only for a particular
     machine type.  On these occasions, the users would benefit if the
     GNU C compiler were to support by default the same dialect as the
     other compilers on that machine.  But such applications are rare.
     And users writing a program to run on more than one type of
     machine cannot possibly benefit from this kind of compatibility.

     This is why GNU CC does and will treat plain bitfields in the same
     fashion on all types of machines (by default).

     There are some arguments for making bitfields unsigned by default
     on all machines.  If, for example, this becomes a universal de
     facto standard, it would make sense for GNU CC to go along with
     it.  This is something to be considered in the future.

     (Of course, users strongly concerned about portability should
     indicate explicitly in each bitfield whether it is signed or not.
     In this way, they write programs which have the same meaning in
     both C dialects.)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com