apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <rbl...@gmail.com>
Subject Re: apr_pcalloc resulting in segfault
Date Thu, 31 Mar 2005 13:26:30 GMT
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.

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.  If the documentation says what is
macro, then that is almost guaranteed to be out of date at some point
in the future.  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?

Ryan

On Thu, 31 Mar 2005 15:08:04 +0200, Uwe Zeisberger
<zeisberg@informatik.uni-freiburg.de> wrote:
> Hello,
> 
> in apr_pools.h[1] the following is defined:
> 
>         #define apr_pcalloc(p, size) memset(apr_palloc(p, size), 0, size)
> 
> If I don't set an abort function and an allocation with palloc fails,
> this results in a segfault.
> 
> There is still a function with this name, so removing the macro would
> fix this and should be as compatible as required.
> 
> I see no way to implement this in a save manner as macro.  One would
> need something like:
> 
>         #define apr_pcalloc(p, size) \
>                 (void *__t = apr_palloc(p, size), __t ? memset(__t, 0, size), __t)
> 
> but I think this doesn't work, or at least is not portable.
> 
> Additionally it would be nice, if in the documentation would appear,
> which functions are realized as macros, above all because sometimes the
> arguments are evaluated more than once.
> 
> Regards
> Uwe
> 
> [1] This is true for HEAD, apr-0.9.x and apr-1.x
> 
> --
> Uwe Zeisberger
> 
> http://www.google.com/search?q=i+squared
> 
> 
> 


-- 
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com

Mime
View raw message