Re: type based aliasing again - meaning of "undefined"

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Ross" == Ross Morgan-Linial <rmorgan@jetcity.com> writes:

    Ross> for (i = 0; some_condition(); i++) { if (i < 0)
    Ross> oops_we_overflowed(); do_something(); }

    Ross> Someone might actually use that somewhere(?).

Yup.  Someday, they'll find `oops_we_overflowed' is never called
because the compiler decided the conditional is always false.

    Ross> Question: would there be a problem with treating (where
    Ross> feasable) undefined behavior that has had a consistent
    Ross> effect, that people actually use, in the same way as
    Ross> deprecated features? That is, warn about them for a few
    Ross> versions before going ahead and breaking them?

Yes, that's a good idea, where feasible, both in terms of giving a
helpful warning and in terms of not taking undue effort to produce the
warning.

As I recall, we did half of this with -fstrict-aliasing; we had a
release where it was off by default, but available.  We didn't have a
warning, though.  I don't think anyone could figure out how to issue a
sensible warning; that's (one) of the things on the table right now.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com