Acces Violation: assert with null instance

[Sean Kelly]

Frits van Bommel wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> Sean Kelly wrote:
>>>> Walter Bright wrote:
>>>>> It does check if it's null. That's how the access violation 
>>>>> exception gets thrown.
>>>>
>>>> But that's generated by the hardware, isn't it?
>>>
>>> Yes.
>>>
>>>> Shouldn't assert explicitly check whether c is null before calling 
>>>> its invariant?
>>>
>>> Why, if the hardware does it for you (without extra bloat)?
>>
>> Just so a file and line number are available.  Though someone 
>> mentioned the code already does something like "assert(obj); 
>> obj.invariant();" and the problem here was that it was a release 
>> build?  If this is the case I'm fine with the current behavior.  I 
>> really only care about this sort of thing if asserts are enabled.
> 
> Yes, an assert(o !is null) is performed. But it's performed *inside* 
> _d_invariant, which is part of Phobos. And since Phobos is only 
> distributed as a release build, that means the assert is off by default 
> _even if *your* program has asserts enabled_. You need to recompile 
> Phobos to change this behavior. This is bad.
> 
> Perhaps that assert should just be converted to an "if (!o) 
> _d_assert(__FILE__, __LINE__)" since _d_invariant will (presumably) only 
> be called if the application has assertions enabled?

I think the problem is more that Phobos only ships with a release build 
rather than that the code is broken.  What should probably be the case 
is that DMD should link phobos.lib if -release is set and link 
phobosd.lib otherwise.  Specifying both -debug and -release... well, I'm 
not sure what that does so I can't say :-)


Sean