This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [c++] switch ( enum ) vs. default statment.
- From: Paweł Sikora <pluto at agmk dot net>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 29 Jan 2007 10:36:01 +0100
- Subject: Re: [c++] switch ( enum ) vs. default statment.
Mark Mitchell wrote:
> For GCC, what happens (though we need not document it) is that the
> value is converted to the underlying type -- but not masked down
> to { 0, 1 }, because that masking would be costly.
> So, "((int) e == 7)" may be true after the assignment above.
> (Perhaps, in some modes GCC may optimize away the assignment because
> it will "know" that "e" cannot be 7,
hhmm :-) this can lead to another felix-like war ;-)
"I DID NOT WRITE THE BROKEN CODE. (...)
IT DOES NOT MATTER WHAT THE ... STANDARD SAYS.
You broke code, people are suffering damage. Now revert it."
> So, now, what should we do about the warning? I think there are good
> arguments in both directions. On the one hand, portable programs
> cannot assume that assigning out-of-range values to "e" does anything
> predictable, so portable programs should never do that. So, if you've
> written the entire program and are sure that it's portable, you don't
> want the warning.
and this is exactly what i'm expecting - no warnings for pure c++ code.
moreover such warnings-on-valid code make -Werror unusable with -Wall.
> On the other hand, if you are writing a portable library designed
> to be used with other people's programs, you might every well want
> the warning -- because you can't be sure that they're not going to
> pass "7" in as the value of "e", and you may want to be robust in
> the face of this *unspecified* behavior.
sorry, i don't care about unspecified/undefined behavior triggered
by users glitches. it's not a problem of my library.
> In practice, this warning from GCC is keyed off what it thinks the
> effective range of "E" is. If it starts assuming that "e" can only
> have the values { 0, 1 }, it will also stop warning about the missing
> case. It would be hard to stop emitting the warning without making
> that assumption, and it may not be easy to make the assumption, but
> still avoid the expensive masking operations.
i'm not familiar with gcc internals. for me enum looks like a set
and detecting missed `case' is a basic operation from set theory.
finally, if PR/28236 is valid then (according to the current discussion)
it should be marked as suspended or resolved/wontfix with appropriate
note.
BR,
Pawel.