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

Re: CVS update: subversion/subversion/libsvn_delta vcdiff_parse.c

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-10-03 23:44:35 CEST

On Tue, Oct 03, 2000 at 05:28:05PM -0400, Greg Hudson wrote:
> > Oh -- actually, that's why I made that change (plus a much larger
> > one right after it). One can't reliably assume that pointer fields
> > in the new structure will be NULL after this? If not, I'll need to
> > change a few places in the code... Can you elaborate? Thanks.
> Basically, when the C compiler sees a constant "0" used in a pointer
> context (via explicit or implicit cast), it will convert it to the
> null pointer. But there is no guarantee in ANSI C that the null
> pointer is represented by all zero bytes internally.]

For all of our target architectures, NULL == 0. Period.

> Question 5.17 enumerates some platforms which don't use all-zero-bytes
> to represent the null pointer, just so you can see the (limited)
> extent of the practical effect.

Prime 50 series, Eclipse MV series, Honeywell-Bull, and CDC Cyber 180 series
are documented in that FAQ as using non-zero NULL pointers. Our software
simply will not ever run on those machines, if any happen to be operational
today *and* people are desiring to load new software onto them.

Please. Let's be rational here, and let pragmatism prevail. This is just
being pedantic for zero benefit (and arguably some cost). NULL == 0. Let's
not add cruft to our code because some creaky old mainframe somewhere
happened to not use that convention.

And *every* system into the future will continue to use the NULL==0
convention. They have to, simply because of precedent and the extent body of
software out there.


Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:10 2006

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