SHORT Re: Suggestion: "fix" assert(obj)

Ary Manzana ary at esperanto.org.ar
Sat Jun 16 18:28:34 PDT 2007


The problem in question is that assert(someObject) doesn't check first 
that someObject is not null, so if it's null, calling it's invariant 
results in a segmantation fault. In code:

assert(someObject);

becomes

assert(invariantOf(someObject));

(where invariantOf is a ficticious function that is the invariant of the 
object)

You can avoid segmentation fault by making the compiler rewrite

assert(someObject);

to

assert(someObject !is null, "someObject is null");
assert(invariantOf(someObject));

Why not do it? In the first case you get a segfault, in the second you 
get a clear "Assert failed in line ..., someObject is null".

Jascha Wetzel escribió:
> Ary Manzana wrote:
>> You'll waste less time to fix the bug if you know which is the line 
>> that causes trouble, instead of doing these three steps: compiling 
>> with symbolic debug info, launching the program again and see where it 
>> crashes.
>>
>> You could even fix the bug by just looking at line 178, without 
>> debugging.
> 
> there is no way how access violations can have line numbers without 
> adding debug symbols (read: line numbers) to the executable.
> imho, using -g should be default during development and testing.



More information about the Digitalmars-d mailing list