Re: [PATCH] Fix for short-enums comparison bug

[Jeffrey A Law <law@hurl.cygnus.com>]

  In message < 199902111942.LAA16560@atrus.synopsys.com >you write:
  > Wrong.  The ISO C++ standard defines what values must be assignable to the
  > enum, and it is a larger set of values than just the members.  I don't
  > have the language in front of me, but the intent is to require the ability
  > to hold intermediate values and AND and OR of legal values.  Thus code
  > like the following is standard-conformant:
  > 
  > enum flags {
  > 	flag_none = 0x0,
  > 	flag_a = 0x1,
  > 	flag_b = 0x2,
  > 	flag_c = 0x4,
  > 	flag_d = 0x8
  > };
  > 
  > ...
  > 	flags foo = (flags)(flag_a | flag+b);	// OK
  > 	flags bar = (flags) 12;			// OK
  > 	flags xyz = (flags) 23;			// not OK
  > 
  > the last one is not guaranteed to work because the compiler is allowed to
  > use a four-bit unsigned field and 23 will not fit.
OK.  Thanks.  So if we go back to the original sample code:


typedef enum {A=0, B, C, D} T;
main(){
  T x;
  for (x=A; x<=D; ++x)
    printf("%d ", (int)x);
  putchar('\n');
}

So the compiler could use a 2 bit unsigned field for x since the values for 
enum T are 0, 1, 2, 3.  Other values will not fit and would be considered
invalid.  Thus removing the test x <= D is technically valid for C++.  Right?

That (of course) isn't binding for C.

jeff