This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: typeof and bitfields
- From: Paul Schlie <schlie at comcast dot net>
- To: <gcc at gcc dot gnu dot org>
- Date: Thu, 13 Jan 2005 20:35:21 -0500
- Subject: Re: typeof and bitfields
> Andrew Pinski wrote
>> On Jan 13, 2005, at 7:12 PM, Matt Austern wrote:
>> So given that "n" has a type, what's the rationale for saying that users
>> aren't allowed to look at that type using typeof? The C++ compiler knows that
>> the type of that field is "int", and I can't think of any reason why the C
>> compiler shouldn't know that too.
>
> The type is one bit size int which is different from int.
> The patch which changed this is
>
> < http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01300.html >
>
> This patch describes the exact type and why this changed and where in the
> C standard this is mentioned.
(disregarding the statement "unsigned:3 bit-field promotes to int in C"
referenced in the above link, which is not generally true, although may be)
Wonder if the integer type/size that is allocated upon access, would be
more useful, consistent, and pertinent for typeof and sizeof to return.
(presuming that an efficient implementation would allocate the smallest
integer type <= to the specified bit-field sign/size, which seems like
what's really useful to know?) i.e. (given: unsigned x:3)
typeof( x ) :: unsigned char
sizeof( x ) :: 1
???
6.5.2 Type specifiers
6.5.2.1 Structure and union specifiers
Semantics
[#8] A bit-field shall have a type that is a qualified or
unqualified version of signed int or unsigned int. A bit-
field is interpreted as a signed or unsigned integer type
consisting of the specified number of bits.91