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

["Dave Korn" <dk at artimi dot com>]

    Blimey.  What a lot of posts there have been to this thread overnight.
And I think mostly because we don't quite have our terminology
straight......


> -----Original Message-----
> From: Joe Buck 
> Sent: 24 August 2004 23:31

> On Tue, Aug 24, 2004 at 02:58:33PM -0700, Mark Mitchell wrote:
> > The people who write testsuites for a living think a lot 
> about corner 
> > cases and try to write tests that cause compilers to get the corner 
> > cases wrong.  They go through the standard line-by-line, 
> thinking of 
> > pathological things.  None of them have ever written the 
> test that David 
> > is suggesting.
> 
> But the suggested test is clearly a non-conforming program, one whose
> behavior is unspecified.  This means that no test suite is likely to
> contain such a program.
> 
> It seems that we are only arguing about what the limits of 
> "unspecified" are.

  It seems to me that "unspecified" and "undefined" are repeatedly being
confused in this discussion.  They are both clearly defined technical terms
in the standard; they have different meanings; everyone participating in
this thread should make very sure they know which one they're referring to
at any time.

  "undefined" is the one that covers rm -rf'ing your hard drive.

  "unspecified" is what the standard says that the result of the truncating
cast we've been discussing is.  That means (IIUIC) that the result has to be
one of the enumeration values, but that the standard does not specify which
_particular_ one.


> -----Original Message-----
> From: gcc-owner On Behalf Of Mike Stump
> Sent: 25 August 2004 00:09

> 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.


  I think this post missed the distinction between unspecified and
undefined.


> -----Original Message-----
> From: gcc-owner On Behalf Of Gabriel Dos Reis
> Sent: 25 August 2004 00:21

> Mike Stump 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. 
> 
> -- Gaby


  I think this post makes it clear.


> -----Original Message-----
> From: gcc-owner On Behalf Of Joe Buck
> Sent: 25 August 2004 00:48

> Joe Buck writes:
> > | I agree with you so far; (E)n might be 7.
> 
> On Wed, Aug 25, 2004 at 01:29:50AM +0200, Gabriel Dos Reis wrote:
> > I disagree that the enum object would have value 7, as 7 is not an
> > enumeration (E) value.
> 
> I attempted to clarify this in the followup; I meant to say that an
> implementation might produce code that still has a 7 at that point,
> because the behavior of the program is unspecified.  Or are 
> you claiming
> that the compiler is *required* to emit code that will transform the 7
> into one of [0,3]?

  This post conflates the two concepts.  If the behaviour was *undefined*,
it would be ok to have an enum with a value that was out of range, or a bool
that was neither true nor false.  But when the behaviour is merely
*unspecified*, you know that the bool *MUST* be true or false, merely that
the standard doesn't specify which, and by analogy, the enum *MUST* be
in-range, but may arbitrarily be any in-range value, the standard doesn't
specify which.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....