[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: pointers and Windows debugging

From: <rbb_at_rkbloom.net>
Date: 2003-01-07 01:19:35 CET

On Tue, 7 Jan 2003, John Barstow wrote:

> Two things I've been noticing in the code lately seem odd. Probably it's
> just my background, but I feel somewhat disquieted by them.
>
> 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.

This generally concerns me. Uninitialized pointers are a huge reason for
bugs. But, knowing the caliber of developer working on Subversion, I
assume there is a good reason. (The obvious one to me, is that if you
don't get any compiler warnings this isn't a big issue. The compiler
should catch unitialized variables in most cases).

> 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.

Asserts are generally a bad thing IMO. If something should be checked in
debug code, it should also be checked in production code. As for pointers
being passed without checking for NULL, those checks are usually a waste
of cycles. If the value is incorrect, then you are most likely to catch
those problems in your debugging. You are more likely to catch those
problems if your program segfaults than if you rely on a log message that
you may miss.

Ryan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 7 01:06:07 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.