Re: typeof and bitfields

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Matt Austern <austern@apple.com> writes:

| On Jan 13, 2005, at 4:49 PM, Gabriel Dos Reis wrote:
| 
| > Andrew Pinski <pinskia@physics.uc.edu> writes:
| >
| > | 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.
| >
| > I think the real issue is not whether the type is int.  But whether
| > "n" has a type. The answer is unambiguous: yes.  typeof should report
| > that type.
| > The C standard allows integer types beyond those explicitly listed.
| 
| I'm finding this discussion a little frustrating because I think there
| is a good argument removing typeof for bit-field types but I haven't
| seen that argument yet.  I've seen a sort of summary of what that
| argument might be, and I'm trying to fill in the gaps.
| 
| Here's my attempt to sketch out what this argument might look like.
|   1. According to the C standard, the type of the field "n" in "struct
| X { unsigned int n : 2; };" isn't "unsigned int", but "unsigned int
| with two bits". [GAP: where does the C standard say this?  I'm not as
| good a C language lawyer as I am a C++ language lawyer, but I don't
| see how to get there from 6.7.2.1.  When I read it, 6.7.2.1 sure seems
| to imply that the type of a bit-field is the type of its
| type-specifier, in this case unsigned int.]
|   2. There's no way to represent a type like "unsigned int with two
| bits" in C.  You can't have variables of that type, for example.  You
| wouldn't be able to take their address.
|   3. Since the only thing typeof could possibly return for a bit-field
| is a type that is inexpressible and unusable for variables, the only
| thing we can do is disable typeof for bit-fields entirely. [GAP: even
| if we agree that in some sense the type of the bit-field is something
| like unsigned-with-two-bits, why not just upgrade it to unsigned for
| the purpose of typeof?  typeof in the C++ front end makes some
| adjustments; typeof in C could too.]

Thanks.  My argument is based on the following 6.2.7/4


       [...]                                              There may
       also  be  implementation-defined  extended  signed   integer
       types.28)  The standard and extended  signed  integer  types
       are collectively called signed integer types.29)

       [#6] For each of  the  signed  integer  types,  there  is  a
       corresponding   (but   different)   unsigned   integer  type
       (designated with the keyword unsigned) that  uses  the  same
       amount  of  storage (including sign information) and has the
       same  alignment  requirements.   The  type  _Bool  and   the
       unsigned  integer  types  that  correspond  to  the standard
       signed integer  types  are  the  standard  unsigned  integer
       types.   The  unsigned  integer types that correspond to the
       extended signed integer  types  are  the  extended  unsigned
       integer  types.   The standard and extended unsigned integer
       types are collectively called unsigned integer types.30)


I don't have argument with "unsigned-with-two-bits".  However, one can
do pretty much all the arithmetic operations on the *values* of that
type.  Therefore, it makes sense to consider it as an implementation
defined integer type, and report that through typeof.  I don't believ
that the "unsigned-with-tow-bits" is a sufficient argument to remove
that particular semantics from typeof in C.

| I'm not endorsing this argument (or rejecting it, for that matter).
| Still just trying to understand what the rationale was.  If I've got
| it completely wrong, I'd appreciate a correction.
| 
| The point here is pretty obvious: we've removed a feature, and this
| will cause some users' code to break.  We should either document this
| new restriction (both in the manual and in changes.html), explain why
| removing this feature made the compiler better, and tell users to
| change their code, or we should put the feature back.  Before we
| decide which of those things we should do, we need a good
| understanding of why this feature was removed in the first place.

Indeed.

-- Gaby