On May 29, 2013, at 1:36 PM, Nevin Liber <nevin_at_[hidden]> wrote:

> On 29 May 2013 14:35, Jens Maurer <Jens.Maurer_at_[hidden]> 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_at_[hidden]>

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