httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Date Wed, 01 May 2002 21:09:13 GMT

On Wednesday, May 1, 2002, at 01:49  PM, Aaron Bannert wrote:

>> 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()?

Umm, no it isn't.  The reason is that it makes the code harder to

>> 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.

Because we have to keep the old API working, and because duplicating code
everywhere is a bad thing.  The arguments have already been made.  I don't
even understand why people are voting on the macro -- just commit it.
Let's save the arguments for things where actual disagreement is useful.

And while we are on the topic, anything that is posted to the mailing
list is open for others to commit to the code base.  That is how we work.
People here are expected to be part-time volunteers, so if one person does
60% of the work and posts it, others should feel free to do the other 40%
and commit the sucker while the originator is sleeping.  The only necessary
part is that it be appropriately attributed in Submitted By.

In this case, there is no excuse for sitting on a bug fix just because
there are stylistic issues about a patch.  The appropriate thing to do
is remove the style changes and commit the fix.


View raw message