On Mon, Jan 06, 2003 at 04:19:35PM -0800, rbb@rkbloom.net wrote:
> 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 reason we don't initialize them is that they don't need to be
initialized :-)
If the first use of a pointer is to assign to it, then putting "= NULL" in
the declaration is a waste. And Philip makes a good case for avoiding it
whenever possible -- it fools the compiler's notion of use before
assignment.
> (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).
Yup. And Philip's periodic runs of valgrind will catch the *really* wacky
ones.
[ but of course that is all moot... we don't write buggy code! ;-) ]
> > 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.
Right.
This and Ryan's followup post mirror my thoughts. We've gone thru all this
during the APR and Apache development, and Ryan and I agree on (at least)
this :-)
Sometimes, an argument check is added to catch things early, when a "wait
for it to fall over" attitude moves the "fall over" too far from the true
failure point. But generally, a pointer passed into a function is
dereferenced right away and you'll see the failure right then.
Oh, and those argument checks usually just abort(). Take a look... there are
quite a few in Subversion, especially the FS code.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 7 04:30:00 2003