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.

[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: Range of enums

  In message <14020.22010.51278.609918@janus.pgt.com>you write:
  > I think this is a not-too-uncommon idiom in C to step through all the
  > values of an enum.  As far as I know this is legal C; I'd really like
  > to know if it isn't.
That's precisely what we're trying to determine.  Whether or not the code is
valid has a significant effect on how we approach the problem.


  > The "illegal" non-member value 4 is never really
  > used, except to terminate the loop.
Yes, and that's one of the critical questions.  If the value 4 is not valid
for the enum, then the enum couldn't hold the value 4 in the first place, so
any comparison for equality with 4 would always be false.

  > And, since this code worked in gcc 2.7.2.x, it will be a source of
  > breakage for some programs as people upgrade from gcc 2.7.2 to
  > egcs/gcc-2.8.
In general, that's not a valid arguement for/against a particular behavior.
Consider if gcc-2.7 happened to generate code which worked for a buggy
program.  Do you really expect egcs or gcc-2.8 to continue to generate code
which happened to work for that buggy program?

I didn't think so. :-)


  > OK, I think I've made my case for this patch; I promise not to post
  > any more on this subject.  I certainly understand if you choose to
  > reject it.  I had fun poking around in the guts of egcs anyhow...
  > I'll go back to doing my real job now!
It's fine to continue to discuss this -- we're trying to determine what
the right thing to do is.  There's nothing wrong with that! :-0

So far it sounds like C doesn't fully specify what should happen here, which
means we probably should operate on the principle of least suprise and allow
it.

It sounds like C++ _may_ allow this optimization, but it's not 100% clear. 
Regardless, I don't see a strong reason for C & C++ to do something different
here.  So if we allow it for C, we should allow it for C++ (unless C++
explicitly disallows this construct and requires a diagnostic, which I do
not believe is the case).

jeff