On May 29, 2013, at 1:36 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

On 29 May 2013 14:35, Jens Maurer <Jens.Maurer@gmx.net> wrote:

 (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.

The counter argument is usually that (4) has a run time cost in that the overflow must now be detected instead of just assumed that it cannot happen.  This effectively penalizes correct programs.

What does "behavior of unrelated code" even mean once we've invoked undefined behavior?

Exactly.

I tell people that "undefined behavior" means "anything can happen: Your program can crash (or not), your computer can explode, your cat can get pregnant, etc".

One of my favorite examples:

void foo ( int *p ) {
#ifdef qLOG
log ( "foo: p => ", *p );
#endif
if ( p == NULL )
// do something

}

There are compiler which, when qLOG is defined, will elide the test for NULL - will not generate code to test p.

Why not? 
* If p != NULL, there's no need to test it
* if p == NULL, we're already into undefined behavior, so who cares?

and it makes the executable smaller and run faster.
Surprising? It certainly was to me the first time I saw it.
Legal? Absolutely.

Do we, the committee, want to forbid this kind of optimization? Why?

-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists@gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki