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

[mrs at wrs dot com (Mike Stump)]

> To: Charles G Waldman <cgw@alum.mit.edu>
> Date: Thu, 11 Feb 1999 00:46:40 -0700
> From: Jeffrey A Law <law@hurl.cygnus.com>

> I'm not a language lawyer -- we really need one to determine what
> the behavior of that code should be.

I disagree.  The gcc documentation has enough.  It says that a
integral number of bytes are used to represent the enum.  And only if
it were a bit field, would an integral number of bits be used.

If a byte is used 4+1 = 5, 5 is > 4, so the loop must stop.  If we
used bitfields, 4+1=0 (when we use 2 bits for the enum).  But the
documentation clearly states and the users expectation is we use a
byte.

Now, if we want to change to document, we _can_ entertain this, and we
can allocate just the number of bits required.  We are allowed to do
this optimization in C++ certainly (if the user can't otherwise tell).
If we do this, then the behavior of the program _is_ correct.

> Date: Thu, 11 Feb 1999 10:31:58 -0700
> From: Jeffrey A Law <law@hurl.cygnus.com>

> Yes the underlying type must be capable of representing all the
> values for the enum.  But does the enum restrict the actual values
> which can be used with the expected results?

It does (for C++), but we don't need to make use of that much latitude
in the standard.  It we can reasonably maye _more_ code work, even
though strickly speaking it isn't portable, we should.