This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Range of enums
- To: Charles G Waldman <cgw at alum dot mit dot edu>
- Subject: Re: Range of enums
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Sat, 13 Feb 1999 01:03:48 -0700
- cc: egcs at cygnus dot com
- Reply-To: law at cygnus dot com
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