This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]