This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]