Re: Article on overzealous compiler optimizations

[Timon Gehr via Digitalmars-d]

On 06/21/2014 12:20 AM, Walter Bright wrote:
http://developers.slashdot.org/story/14/06/20/1824226/overeager-compilers-can-open-security-holes-in-your-code

This is an opportunity for D to define the spec in such away as to
preclude the bad optimizations while keeping the good ones. Any ideas?

A possibility is to have no undefined behaviour in standard language 
features and to add unsafe intrinsics for the cases where the optimizer 
_actually_ needs the help for generating fast enough code for a hot 
spot. (Of course, a type system that is able to preclude more of the bad 
behaviours in the first place can help too.)

E.g.

int foo(Foo* foo)@safe{
    return foo.bar; // defined behaviour in all cases
}

int bar(Foo* foo)@system{
    return __assume_non_null(foo).bar; // undefined behaviour if foo is 
null
}