Re: Range of enums

[Jeffrey A Law <law at hurl dot cygnus dot com>]

  In message <14019.1393.628352.129795@janus.pgt.com>you write:
  > 
  > Jeffrey A Law writes:
  > 
  > >I don't have an ANSI C standard here, nor do I have a copy of the ISO C9X
  > >standard.  Can someone who does dig into them and determine what happens f
  > or
  > >an assignment out of the range of an enumerated type and what assumptions 
  > the
  > >compiler can/can not make about the values an enumerated variable can have
  > ?
  > 
  > It would certainly be difficult to try to enforce enum assignment to
  > only allow legal enum values.  It's not just a matter of the range of
  > the enum, as this example shows:
  > 
  > typedef enum{A=0, B=5, C=11} T;
  > 
  > foo(){
  >   T x;
  >   x = 6;
  > }
  > 
  > You'd have to check every assignment, not just against a max and min
  > value, but against every legal enum value.  I think this can't be done 
  > at compile-time... suppose I had written:
Yes.


  >   T x;
  >   x = some_function();
  > 
  > Ensuring at compile-time that some_function() only returns 0, 5, or 11
  > is equivalent to the Halting Problem.
Yes.  This is pretty typical of standards -- if giving an accurate warning
requires solving the halting problem, then no diagnostic is required.  That
doesn't mean we can't go ahead and warn when we see something bad.  It just
means that the compiler is not required to issue a diagnostic.


  > The only reasonable thing to do is to consider the range of an enum to 
  > be the same as the range of its underlying integral type.
I'm still not sure.  The C++ standard appears to say that assigning a value
to an enum that is not one of the members of the enum produces undefined
results.  My interpretation may be wrong and (of course) the C++ standard is
not binding on C.

jeff