apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: cvs commit: apr/memory/unix apr_pools.c
Date Thu, 07 Oct 2004 21:04:22 GMT
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.


View raw message