Re: pointers and Windows debugging

John Barstow <John_Barstow@gfsg.co.nz> writes:

> 1) Pointers are not initialized to NULL. This may not matter too much on
> Unix, but on Windows, uninitialized pointers point to random locations in
> memory. This makes debugging very painful and bugs very unpredictable -
> especially since the problem is less pronounced in debug mode.

Not sure why you say this affects Windows more than Unix.

> 2) There are no asserts() or other debug-time checks of parameters. Maybe
> this activity is being masked by macros, but I see pointers being passed,
> then used, with no checks for NULL values. I don't expect a C program to be
> doing runtime checks, but I do generally expect debug-time checks.
>
> I know there have been bugs involving uninitialized ponters, if not as many
> as I might expect.

Running programs under a memory checker like purify or valgrind will
detect all attempts to use unitialised memory. I have run most of the
test suite under valgrind in the past. Adding needless initialisation
will make it harder to find such bugs using these tools.

> Is there a reason we don't do these things?

I object to needless initialisation, I believe it leads to more opaque
code. From that it follows that asserting that a pointer is not null
is not very useful as invalid non-null pointers will not be caught.

Even if needless initialisation is added, pointers that are no longer,
but were once, valid (a pool was cleared say) will not be detected.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org