This is the mail archive of the
mailing list for the GCC project.
Re: typeof and bitfields
- From: Paul Schlie <schlie at comcast dot net>
- To: <austern at apple dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Fri, 14 Jan 2005 01:31:49 -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
22.214.171.124 Structure and union specifiers
[#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