assert(0) behavior

[Steven Schveighoffer via Digitalmars-d]

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