🚀 go-pugleaf

danielv@crt0.crt (Daniel Villeneuve) wrote:
>In article <446v7l$jn4@gozer.inri.com> pde@zymurgy (Paul D. Eccles) writes:
>> Do bit fields have to be of type unsigned int or can I use an enum, unsigned
>> short, or unsigned char?  My compilers (gcc 2.6.3 and HP cc) let me use all
>> of them without complaint.
>
>From ANSI C 3.5.2.1:
>
>``A bit-field shall have a type that is a qualified or unqualified version
>of one of _int_, _unsigned int_ or _signed int_.''
>
>With gcc, you may try some of the warning switches, maybe `-ansi
>-pedantic', to get the warnings for these erroneous constructs.

The sentence that you quote is from a Semantics section, not a Constraint
section. A diagnostic is therefore not required.

In their strictest ANSI-C mode, Sun's acc does not complain about enum,
unsigned short, or unsigned char bit fields (unsigned/signed doesn't matter)
and gcc 2.6.0 does not complain about an enum bit field, but it does complain
about unsigned short and char bit fields. A Standard C compiler is not required
to generate a diagnostic for these bit-field types.

BTW, how's this for perverse? The 6.5.2.1 Semantics section says that "A
bit-field is interpreted as an integral type consisting of the specified number
of bits." So, as long as we "interpret" the type as integral, does this mean
that the following is conforming?

   struct {
      float a : 3;
   };

IOW, it looks like the Standard imposes NO requirements for the type of a
bit-field. We just have to interpret the type as integral. Can anybody prove
different? This would make a lot of C compilers non-conforming, such as acc and
gcc.

-- 
Paul Long                               45:29:14N 122:48:09W
plong@perf.com                          http://www.teleport.com/~pciwww/
    "Where time or intelligence are lacking, a goto may do the job."
        - M.E. Hopkins, "A Case for the GOTO," 1972.