On 29/01/07, Paweł Sikora <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
> 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.
We do emit a lot of warnings for pure and valid c++ code. See
-Wunused-*, see -Wparentheses, see -Wuninitialized, see
-Wchar-subscripts, see -Wsign-compare, etc. Some could be avoided if
we had dataflow information in the front-end, but others are given
because there is a serious suspicious that something could go wrong
despite the code being valid and pure C++.
> 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.
You have many ways to work-around it if you are 100% sure you are the
only one using that function and that you will never pass anything
different from that enum type.
* You can add a return 0 or an exit(1) at the end of the function or
in a default label. Since in your case the code is unreachable, the
optimiser may remove it or it will never be executed.
* You can use the appropriate -Wno-X option to disable the warning.
* You can use the appropriate #pragma GCC diagnostics ignored "-WX" to
disable the warning.
* You can use #pragma GCC diagnostic warning "-WX" to emit just a
warning despite using -Werror in the command-line. You do the same
with -Wno-error=X.
> 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.
Out-of-range values are unspecified, they can be within the range of E
and they can be outside. Currently, GCC generates out-of-range values,
so we warn you about it. If GCC modified the value to fit within the
range (maybe randomly), it still will be correct but we won't generate
any warning. Yet, people will also complain that they cannot detect
when the value was out-of-range and will request a warning. Hey! one
moment! it seems we already did that at some moment and people did
complain! http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
finally, if PR/28236 is valid then (according to the current discussion)
it should be marked as suspended or resolved/wontfix with appropriate
note.
I think it should be marked as invalid but WONTFIX is ok as well.
Since you agree, I will close it right now and point to your message.
Cheers,
Manuel.
