Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: domain of jorton@redhat.com designates
 66.187.233.31 as permitted sender)
Date: Thu, 7 Oct 2004 22:06:17 +0100
From: Joe Orton <jorton@redhat.com>
To: dev@apr.apache.org
Subject: Re: cvs commit: apr/memory/unix apr_pools.c
Message-ID: <20041007210617.GB6877@redhat.com>
Mail-Followup-To: dev@apr.apache.org
References: <20041007192855.95748.qmail@minotaur.apache.org>
 <20041007202934.GA6834@redhat.com> <4165ACF5.1080709@us.ibm.com>
 <20041007210422.GA6877@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20041007210422.GA6877@redhat.com>
User-Agent: Mutt/1.4.1i

On Thu, Oct 07, 2004 at 10:04:22PM +0100, Joe Orton wrote:
> On Thu, Oct 07, 2004 at 04:54:13PM -0400, Allan Edwards wrote:
> > Joe Orton wrote:
> > >Why is this a macro? It's not like apr_uint32_t is a name which is going
> > >to change any time soon?
> > 
> > It's a macro because we don't want to lose sight of the
> > fact that we did something there that we utimately want to
> > back out (i.e. in APR 2.0 when we can change the API). If
> > we used apr_uint32_t it would be easy to lose track of
> > these places - make sense?
> 
> The fact that these casts are unnecessary can be tracked using comments,
> a list of issues in STATUS, or, not wishing to rock the boat, bugzilla.
> Using a macro just obfuscates the code.

s/unnecessary/undesirable/