This is the mail archive of the 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

On Jan 13, 2005, at 4:49 PM, Gabriel Dos Reis wrote:

Andrew Pinski <> 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 When I read it, 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.]

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.


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