On Mon, 2003-01-06 at 19:11, Philip Martin wrote:
> 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.
In Unix, an uninitialized pointer might, conceivably, scribble over
memory owned by the current application. But it's much more likely to
cause a bus error or segmentation fault. In Windows, as I understand
the argument, an unintialized pointer might scribble over memory owned
by another application, or by the OS.
I thought Windows XP made this a non-issue. And at any rate, I don't
recall us having any bugs with uninitialized pointers. The compiler
catches most of that.
> > 2) There are no asserts() or other debug-time checks of parameters.
I use asserts to check for what I feel might be non-obvious
failures--passing one valid parameter and one invalid parameter when
they are supposed to be both valid or both invalid; attempting to refill
an input buffer which has not been totally consumed; stuffing an
out-of-range offset into a delta window opcode. If these things happen
and are not caught by the assertions, they may be difficult to debug (or
they may go unnoticed until some implementation is changed).
But if we had an assert everywhere where a pointer argument is never
supposed to be NULL, that would add significantly to the bulk of the
code without adding much value.
(As far as I know, assertions are always turned on unless you compile a
program with NDEBUG defined. We have no build support for defining
NDEBUG, so I don't buy the argument that assertions are harmful because
they might be turned off. If our assertions have been turned off, it's
because someone tried hard.)
---------------------------------------------------------------------
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:40:50 2003