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.
