Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Wed, 1 May 2002 13:49:44 -0700
From: Aaron Bannert <aaron@clove.org>
To: dev@httpd.apache.org
Subject: Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Message-ID: <20020501134944.U14899@clove.org>
Mail-Followup-To: Aaron Bannert <aaron@clove.org>, dev@httpd.apache.org
References: <20020501071540.31410.qmail@icarus.apache.org>
 <20020501122213.T14899@clove.org> <20020501124243.N25026@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020501124243.N25026@apache.org>
User-Agent: Mutt/1.3.23i

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

-aaron