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

[Mark Mitchell <mark at codesourcery dot com>]

Mike Stump wrote:

> On Tuesday, August 24, 2004, at 12:37  PM, Gabriel Dos Reis wrote:
>
> > | > The enum case is more like NaNs
> > |
> > | ?  Can you please back this by citing the standard?
> >
> > 7.2/6
> >   For an enumeration where emin is the smallest enumerator and emax is
>
>
> Let me try it a different way...   I am skeptical that taking 
> additional advantage of rules that exist in C++ and not C is wise.  
> Everything else flows from that.

That's a different issue.  Not a bad one to discuss, just different.

The first issue is "what does the standard require?"; the second is 
"what should we do?".

The standard is just plain not clear here.  There's nothing that says 
definitively what should happen, either with the conversion or with the 
subsequent use, assuming that conversion to a value outside the enum 
range is permitted.  The only thing it says is that the conversion is 
unspecfied. 

Since C does not apply a mask on the conversion, I think your logic 
suggests that C++ should not do so either.  I think most people have 
taken that viewpoint: it's consistent with C, and it avoids generating 
code that will not be useful for the vast majority of conversions.  So, 
let's ignore the minority viewpoint that we should be masking the 
conversion, for the moment. :-)

Now, what should we do at the point of use?  Assume the value is a valid 
value in the enumeration type (and thereby crash, on Roger's jump-table 
example), or assume that the value may be any valid value in the 
underlying type?  The standard does not say definitively one way or the 
other.  There is, in my opinion, no evidence that the authors of the 
standard considered this case.  (They did consider that an enum with the 
range [0, 7] might be stored in 1 byte -- but I don't see evidence that 
they considered what storing 12 in that byte might mean.)

I think reasonable people can disagree here.  If you're running C code 
through a C++ compiler, you like the any-value-in-underlying-type 
assumption.  But, you will still get burned if you try to store 1000 in 
the enum with range [0,7]; it just isn't going to fit in one byte.  So, 
if you've got shorter-than-int enums, some C code isn't going to work 
anyhow; it's just a question of degree.  If you're writing brand-new C++ 
code, you probably want maximum optimization, and you'd like to have the 
compiler realize that a switch statement is exhaustive, for example.

One possibility is to set TYPE_PRECISION to the full width of the 
underlying type with flag_short_enums is false.  If the user/ABI wants 
small enums, then figure that we might as well consider them as small as 
permitted by the standard; otherwise, go for the more C-ish 
interpretation.  On most platforms, flag_short_enums is false, giving 
the interpretation you want.

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com