apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uwe Zeisberger <zeisb...@informatik.uni-freiburg.de>
Subject Re: apr_pcalloc resulting in segfault
Date Thu, 31 Mar 2005 13:50:09 GMT

Ryan Bloom wrote:
> I really don't think we should take a function like apr_pcalloc and
> convert it to a macro.  The only reason to go to a macro is for
> performance reasons.  First, the performance boost should be
> relatively minimal, and for anybody who needs it, they can use
> apr_palloc and memset themselves.
I agree, I only suggested a macro as it is one now.

> As for documentation mentioning if it is a function or macro, I don't
> think we should do that.  macros should be written so that arguments
> aren't evaluated multiple times.
In general there is also the problem of taking the address of a
function/macro.  i.e.

	alloc_func = &apr_pcalloc;

doesn't work when apr_pcalloc is a macro.

> If the documentation says what is macro, then that is almost
> guaranteed to be out of date at some point in the future.
That's an alltime present problem with documentation.  I think doxygen
can distinguish these two cases.

>  And, what happens when sometimes it is a function and
> sometimes it is a macro, depending on the compiler used or what
> #defines are set?
One more reason to say something like: "This is sometimes a macro and
sometimes a function".  If a developer uses something like taking the
address of a function/macro, it works on his platform and there is no
hint, that it doesn't on an other.


Uwe Zeisberger


View raw message