Help with bit-field semantics in C and C++

[David Carlton]

On Tue, 24 Aug 2004 16:09:02 -0700, Mike Stump <mrs@apple.com> said:
> On Tuesday, August 24, 2004, at 02:42  PM, David Carlton wrote:

>> Just to clarify: I agree that, it's okay if, on one run of the
>> program, the program behaves as if it's 0 and on another run of the
>> program, the program behaves as if it's 1, or other similar
>> pathologies.  But I don't see how the standard allows the program to
>> behave as if the value is neither 0 nor 1.

> (E)n, where n is an int with value, say of 7, is permitted by the
> standard to take on the value 7.  This is because the text of the
> standard says the value is unspecified.  7 is a unspecified value,
> honest.

7 is an unspecified value of something, but it's not an unspecified
value of the enumeration in question, because it's not a value of the
enumeration in question in the first place.  This is relevant because
of 7.2p9: "The resulting ENUMERATION VALUE is unspecified" (emphasis
mine) and because of 7.2p6: "The values of the enumeration are the
values of the underlying type in the range ...", where the range in
question doesn't contain 7.  If the author of the paragraph had meant
to include values outside of the range of the enumeration, then why
did the author write "enumeration value" as opposed to just, say,
"value" or "value of the underlying integral type"?  (Possible answer:
a simple mistake, as Mark says.)

Having said that, I'll shut up now; I think people know my opinion
now, and I agree with Mark that, given the disagreement here, a DR
would probably be an appropriate next step.  (And I would hope that
people would take that step before implementing behavior that, say, I
disagree with. :-) )

David Carlton
david.carlton@sun.com