On 8/3/15 11:57 AM, Dicebot wrote:
On Monday, 3 August 2015 at 15:50:56 UTC, Steven Schveighoffer wrote:
On 8/3/15 11:18 AM, Dicebot wrote:
On Monday, 3 August 2015 at 14:34:52 UTC, Steven Schveighoffer wrote:
Why do we do this?
Because all asserts must be completely removed in -release
1. They aren't removed, they are replaced with a nearly useless segfault.
2. If we are going to put something in there instead of "assert", why
not just throw an error?
Effectively:
assert(0, msg)
becomes a fancy way of writing (in any mode, release or otherwise):
throw new AssertError(msg);
This is actually the way I thought it was done.
Now, they are completely removed. There is effectively no AssertError
present in -release (it is defined but compiler is free to assume it
never happens). I'd expect any reasonable compiler to not even emit
stack unwinding code for functions with assert(0) (and no other
throwables are present).
I actually don't care if stack is unwound (it's not guaranteed by
language anyway). Just segfault is not useful at all to anyone who
doesn't have core dump enabled, and even if they do enable it, it's not
trivial to get at the real cause of the error. I'd settle for calling:
__onAssertZero(__FILE__, __LINE__, message);
Which can do whatever we want, print a message, do HLT, throw
AssertError, etc.
assert(0) is effectively same as gcc __builtin_unreachable with all
consequences for optimization - with only difference that latter won't
even insert HLT but just continue executing corrupted program.
No reason this would change. Compiler can still consider this
unreachable code for optimization purposes.
-Steve
