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

[David Carlton <david dot carlton at sun dot com>]

On Tue, 24 Aug 2004 14:45:14 -0700, Mark Mitchell <mark@codesourcery.com> said:
> David Carlton wrote:
>> On Tue, 24 Aug 2004 14:11:17 -0700, Mark Mitchell
>> <mark@codesourcery.com> said:

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

>> But that last assumption isn't correct, is it?  I don't see how that's
>> consistent with 7.2p9: it talks about "the resulting enumeration
>> value", which should surely mean that a value outside the enum range
>> _isn't_ permitted.

> I think you're reading too cleverly.

I'm certainly not intending to be clever here.  I would say, actually,
that I'm trying to be as naive as possible in my reading.

> When reading the C++ standard, it pays to remember that it's big,
> complex, and some parts are better written than others.  The people
> writing it just didn't think of all the corner cases, whichi is not
> to criticize; it's just a fact.  I know of no compilers that do as
> you suggest, and I think it would disappoint users to have extra
> conversion instructions inserted.

I dunno.  I ran this example:

  enum Small { Zero = 0, One = 1, Two = 2, Three = 3 };

  Small x = (Small) 7;

  switch ( x ) {
    case Zero:
      return zero();
    case One:
      return one();
    case Two:
      return two();
    case Three:
      return three();
  }

by a couple of people who walked by my cubicle, before showing them
the standard.  Their first reaction is that they would expect the
switch statement to fall through.  When I showed them the standard,
they agreed that it wouldn't fall through.

So, based on that limited sample size, I will say:

* I'm not the only person who thinks that the standard clearly says
  that the conversion has to result in a legal enum value.

* Users would be disappointed if the above example were to, say, core
  dump (which is behavior that is being proposed in some messages on
  this thread).

Having said that, after I sent my last message, I noticed the
following (footnote 42 to 3.9.1p6):

  Using a bool value in ways described by this International Standard
  as "undefined," such as by examining the value of an uninitialized
  automatic variable, might cause it to behave as if [it] is neither
  true nor false.

The spirit of that footnote is, to some extent, evidence against my
point of view.  I'm not familiar enough with the entirety of the
standard to know what other remarks along those lines it contains.

David Carlton
david.carlton@sun.com