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

[Mark Mitchell <mark at codesourcery dot com>]

Gabriel Dos Reis wrote:

> Mike Stump <mrs@apple.com> writes:
>
> | 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.
>
> In the  example, 
>
>   enum E { zero = 0x00, one = 0x01 };
>
> for which the minimum bits of representation is 1, 7 is not an
> enumeration value.  A fortiori, it is not a honest unspecified
> enumeration value. 
>  
The same people have now said the same things repeatedly, and it doesn't 
look like anyone's mind is changing.  We can all argue our positions 
until we're blue in the face, but what's the point?  I'm bored.

There's a conservative choice here: set TYPE_PRECISION to match the 
underlying type.  That might pessimize the odd switch statement (because 
the compiler can't tell that all the valid values are used); oh, well.  
Roger's testing that change, which will fix an example on which everyone 
we agrees we generate wrong code.  Any other fix looks riskier, so we 
will go with the easy, safe fix for 3.4.2. 

If someone can show that shrinking TYPE_PRECISION again will win big for 
real code, then we can have this debate again.  And, if you would submit 
a DR, asking for a clarification, that would be very productive, as that 
will avoid having to have this argument again the next time.

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