assert semantic change proposal

[David Bregman via Digitalmars-d]

On Sunday, 3 August 2014 at 20:05:22 UTC, bachmeier wrote:
> Thanks for the summary. I apologize for the uninformed 
> question, but is it possible to explain how the change wrt 
> assert will break existing code? Those details are probably 
> buried in the extensive threads you've referenced. I ask 
> because my understanding of assert has always been that you 
> should use it to test your programs but not rely on it at 
> runtime.
>

Yes, it was discussed in the threads. The basic way it happens is 
something like this:

assert(x);
if(!x) {
  // some side effect on the program
  // the optimizer will remove this path under the proposal
}

It's much more insidious if the assert and the if are separated 
by some distance, such as being in different functions or even 
modules.

for example:

assert(x < 1000); // this assert is wrong, but has never been hit 
during testing. unfortunate but real life programs are not bug 
free.
someFunction(x);

now suppose someFunction is a library sort of function, coded in 
"defensive programming" style. It does something important so it 
validates its input first to make sure nothing bad happens. But 
now someFunction is inlined, and code is generated with the 
(wrong) assumption that x<1000. The input validation checks are 
removed by the optimizer. As a result, someFunction runs with 
invalid input, and [user's harddrive is formatted, hacker gains 
root access, etc].


There are other ways too. The code does not explicitly need to 
have an if statement checking for !x to be broken by this - any 
implicit checks, any kind of control flow structures can be 
broken just the same.