This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
> 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.