Re: typeof and bitfields

[Paul Schlie <schlie at comcast dot net>]

> Joseph S. Myers wrote:
>> 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.
> ...
> 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.
> ...

After reviewing PR10333 which the patch references, it would appear that
the patch more accurately tries to bury the issue, than attempting to remedy
it by implementing a reasonably conformant expected behavior?

With respect to "bit-fields outside of structures and unions", as there
would seem to be no valid reason not to expect equivalent semantics; nor
should the proper implementation of the expected semantics of a feature
which another feature depends on, justify disabling it posed as a bug fix?

So it would seem that as the typeof operator should be expected to yield a
valid signed/unsigned:<bit-size> integral type, which may be subsequently
used to declare other similar types, within or outside structure or union
declarations, it should be implemented to do so, or be considered a bug.

Correspondingly with respect to sizeof, as it is defined to return the size
of the object in bytes, it seems substantially more reasonable for it to
correspondingly return the minimum number of bytes required to hold it's
specified size, possibly even further constrained to integer type sizes
supported by the target, which is likely substantially more more useful than
claiming it's invalid to request the effective size of a bit-field in bytes?

(it would seem that both of these may be supported and be fully conforming)