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