On Wed, May 29, 2013 at 12:35 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
On 05/29/2013 09:00 PM, Lawrence Crowl wrote:
> We also need to define the consequences of senseless behavior.
> In many cases, the consequences may be unbounded, which we currently
> call undefined behavior.  In other cases, we may limit the actions
> possible for senseless behavior.  For instance, we may require the
> implementation to call a no-return handler.
>
> In either event, we must give compilers lattitude to emit diagnostics
> at compile time, at link-time or at run-time.  Much of this behavior
> well likely be driven by compiler flags.  However, in some cases,
> performance is inconsistent with diagnostics and we must admit
> unbounded consequences.  However, unbounded consequences in the
> language definition does not necessarily imply unbounded consequences
> in the compilers.  Compilers and programmers need the freedom to
> detect and react to senseless behavior in a manner appropriate to
> the application.

It seems plausible to limit the possible consequences of senseless
behavior in certain cases, along C11 annex L.

Signed integer overflow is a fairly good example here, I believe:

 (1) Is a compiler diagnostic acceptable?  Yes.
 (2) Is a run-time abort acceptable?  Yes.
 (3) Is an unspecified result value acceptable?  Yes.
 (4) Is it acceptable that your compiler changes the behavior
of unrelated code that follows the overflow?  That's very surprising.

Giving compilers latitude to choose among 1-3 (depending on the
target audience) is fine, but, in my opinion, prohibiting option 4
would be an improvement.

I don't think we should make such judgments before considering all the consequences. For instance, there are some optimizations which compilers only perform if they can show a loop terminates or compute a loop trip count, and the fact that signed overflow has undefined behavior allows compilers to prove that some loops terminate. This can have very far-reaching benefits which we may not want to lose.