• Walter Bright (3/3) Jun 20 2014 http://developers.slashdot.org/story/14/06/20/1824226/overeager-compiler...
• Walter Bright (3/6) Jun 20 2014 Better link:
• bearophile (5/8) Jun 20 2014 Such optimizations are one of the causes that make memory-unsafe
• Timon Gehr (14/17) Jun 20 2014 A possibility is to have no undefined behaviour in standard language
• Jonathan M Davis via Digitalmars-d (12/16) Jun 22 2014 I applaud the sentiment, but I fear that I don't know enough about compi...
• Shammah Chancellor (5/24) Jun 23 2014 Sounds like the oracle query optimizer. 95% of the time it does the

Walter Bright <newshound2 digitalmars.com> writes:

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?

Walter Bright <newshound2 digitalmars.com> writes:

On 6/20/2014 3:20 PM, 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?

Better link:

http://css.csail.mit.edu/stack/

"bearophile" <bearophileHUGS lycos.com> writes:

Walter Bright:

 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?

Such optimizations are one of the causes that make memory-unsafe 
the D reliance of null pointer segfaults, even in  safe functions.

Bye,
bearophile

Timon Gehr <timon.gehr gmx.ch> writes:

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
}

Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Friday, June 20, 2014 15:20:17 Walter Bright via Digitalmars-d wrote:
 http://developers.slashdot.org/story/14/06/20/1824226/overeager-compilers-ca
 n-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?

I applaud the sentiment, but I fear that I don't know enough about compiler
optimizations to have much in the way of good ideas. It seems like every time
the subject comes up, it turns out that compilers do all kinds of crazy things
that make it so that half of what you think is guaranteed isn't guaranteed.
If you had some way to mark code such that it restricts what the compiler can
optimize, then that could help, but you'd have to know that you needed that
restriction in the first place, and usually, the problem is that you don't
even know what the compiler might optimize out, and not even checking the
generated assembly helps in the general case, because what one compiler might
leave in, another might optimize out. It's a thorny problem.

- Jonathan M Davis

Shammah Chancellor <anonymous coward.com> writes:

On 2014-06-22 19:32:45 +0000, Jonathan M Davis via Digitalmars-d said:

 On Friday, June 20, 2014 15:20:17 Walter Bright via Digitalmars-d wrote:
 http://developers.slashdot.org/story/14/06/20/1824226/overeager-compilers-ca
 n-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?

 
 I applaud the sentiment, but I fear that I don't know enough about compiler
 optimizations to have much in the way of good ideas. It seems like every time
 the subject comes up, it turns out that compilers do all kinds of crazy things
 that make it so that half of what you think is guaranteed isn't guaranteed.
 If you had some way to mark code such that it restricts what the compiler can
 optimize, then that could help, but you'd have to know that you needed that
 restriction in the first place, and usually, the problem is that you don't
 even know what the compiler might optimize out, and not even checking the
 generated assembly helps in the general case, because what one compiler might
 leave in, another might optimize out. It's a thorny problem.
 
 - Jonathan M Davis

Sounds like the oracle query optimizer.   95% of the time it does the 
right thing, but convincing it to behave the other 5% of the time is a 
real trick.

-Shammah