Clash of the Gregs! Clash of the Gregs!
:-)
Anyway: it seems to me that this is a mostly matter of taste, and that
Subversion does not need a policy about it. It's certainly very clean
and reliable to explicitly initialize fields, and Greg H if you'd
prefer to revert the recent palloc-->pcalloc change where it touched
your code, obviously I won't object (nor be offended).
I think I'm going to continue to use zeroing myself, though, because
most of the structures I'm working with are designed to have "default"
field states of 0/NULL.
-K
Greg Stein <gstein@lyra.org> writes:
> On Tue, Oct 03, 2000 at 04:12:55PM -0500, Karl Fogel wrote:
> > Greg Hudson <ghudson@MIT.EDU> writes:
> > > > + (svn_txdelta_window_t *) apr_pcalloc (parser->subpool,
> > > > + sizeof(svn_txdelta_window_t));
> > >
> > > So, zeroing out the bytes of a pointer and assuming it will have the
> > > value of NULL is not correct C, although it tends to work in practice.
> > > (It's also not clean, in my opinion, even with integral types.) So
> > > any pointer fields of the allocated svn_txdelta_window_t should not be
> > > assumed to be NULL. If you're aware of this and don't care, that's
> > > okay, but I thought I'd make sure.
> >
> > 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?
>
> Yes, one can. calloc/apr_pcalloc are designed to zero out the allocated
> memory very quickly, and are thus very useful for initializing data
> structures. This includes NULL pointers.
>
> See my other note for my rant. apr_pcalloc() is an entirely valid use, and
> can prevent a lot of manual field initialization in a structure. Please
> don't add manual NULL initializations... that is unnecessary cruft.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:10 2006