httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Date Wed, 01 May 2002 20:49:44 GMT
> And, consider my position on your calloc change in this patch as a
> veto.  If you want to remove calloc, then you should do so throughout
> the code rather than in sporadic places that may make maintaining the
> code a nightmare if we were to fix calloc.  But, that is an issue
> that is now open in APR's STATUS.

What exactly are you vetoing? My use of apr_palloc()+memset() is
technically superior to apr_pcalloc(). What is your technical reason
for forcing me to use apr_pcalloc()?

> If the end result of the calloc vote is that we should remove calloc,
> then feel free to do a search and replace across the entire tree.
> Until then, let's please remain consistent to our API.  -- justin

I'm really not sure about the macro yet. On the one hand it's too
late to remove apr_pcalloc(). The macro stinks the same way #define
safe_free()-like stuff does, but at least it is a compromise. OTOH,
as Cliff brought up, we'll get a SEGV if apr_palloc() returns NULL. I
don't see how:

foo = apr_palloc(p, sizeof(*foo));
memset(foo, 0, sizeof(*foo));

is any less desirable than:

foo = apr_pcalloc(p, sizeof(*foo));

It is quite obvious how the memory is being initialized in both cases,
and for the reasons discussed earlier it is obvious why the first would
be optimal.


View raw message