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.