Re: typeof and bitfields

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 13 Jan 2005, Matt Austern wrote:

> Consider the following code:
> struct X { int n : 1; };
> void foo() { struct X x; typeof(x.n) tmp; }
> 
> With 3.3 it compiles both as C and as C++.  With 4.0 it still compiles as C++,
> but it fails when compiled as C with the error message:
> foo.c:2: error: 'typeof' applied to a bit-field
> 
> This was obviously a deliberate change.  However, I don't see any mention

Yes.  It was <http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02313.html>, 
fixing bug 10333: fixed in 3.4.  The logic is that typeof should be like 
sizeof in this regard, as bit-fields outside structures and unions don't 
make sense; this may also apply, mutatis mutandis, in other ways, for 
example typeof should evaluate its operand iff it is of variably modified 
type.  It was also the case that at that time bit-field variables created 
this way simply didn't work, although now they might.

> about it in the part of the manual that documents typeof.  I also can't guess

After all, it was fixing a known bug, rather than removing an intended 
feature.  Following the link from the 3.4.0 release notes to show bugs 
listed as fixed in 3.4.0 duly lists that bug.

> why this should be different in C and in C++, or what the rationale for the
> change might have been in the first place.  Sure, applying sizeof or alignof
> to a bit-field makes no sense.  But typeof?  X::n has a perfectly good type,
> as the C++ compiler understands.

In C, bit-fields have special types, "interpreted as a signed or unsigned 
integer type consisting of the specified number of bits"; hence also the 
reference to "the number of bits in an object of the type that is 
specified if the colon and expression are omitted" in 6.7.2.1#3 (which is 
distinct from the actual type of the bit-field after modification by the 
colon and expression).  This wording is deliberately clarified from that 
in C90, which said "In addition, a member may be declared to consist of a 
specified number of bits (including a sign bit, if any)." and "the number 
of bits in an ordinary object of compatible type", to make the responses 
to DR#015, DR#120, DR#122 follow more clearly from the standard.  C++ 
chose a different approach, saying "The bit-field attribute is not part of 
the type of the class member." [class.bit], and as the decltype proposals 
don't mention bit-fields specially I suppose decltype is meant to return 
the declared type.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)