On Tue, May 02, 2000 at 03:28:15PM -0400, Noel L Yap wrote:
> [EMAIL PROTECTED] on 05/02/2000 03:13:34 PM
> >i agree in principle ;). It probably would be better to
> >use calloc, within the xmalloc call( as that calloc will zero
> >out the memory for you ), then malloc.
>
> Larry's convinced me otherwise. IMHO, the "right" way to fix the problem is to
> have constructor-like functions to initialize the memory. This would always
> guarantee that the memory is initialized properly (given that anyone who changes
> the structure also changes the constructor -- but at least it'd be easier to see
> what needs to be changed).
I think both are 'right' solutions. Larry's solution ensures that the
constructor function knows the right thing to do. Forcing xmalloc
to 0 out the newly malloc'ed block is also a good thing to do. If
you do not 0 out a new block of memory, it's possible to accidently
( via a bug in the program ) write over memory that you didn't intend
to thus causing a crash later on in the program. If the memory
has been zero'ed out you'll get a null pointer dereference right there
thus helping debug the problem faster.
>
> >Although looking at the xmalloc call, I don't know if it's such
> >a good thing for it to take a 0 length request and turn it into
> >a 1 byte request. Why would we need to ask for a 0 length portion
> >of memory?
>
> I was looking at that, too. I tend to feel that 0-byte allocations should be
> allowed (returning NULL) and, if systems' frees don't handle NULL properly,
> there should be an xfree() that'll do so.
I agree. xfree() should be implemented.
donald
>
> Noel
>
>
>
