apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Striker <s.stri...@striker.nl>
Subject Re: apr_pcalloc resulting in segfault
Date Thu, 31 Mar 2005 13:37:21 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.

apr_pcalloc has been a macro for a very very long time now.  The
performance boost was significant is my recollection.  This is why
we converted to the macro.

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

Agreed.  We can certainly do that.

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

It's a function when pool debugging is enabled.  Both the function and
the macro will be present, so linking is always possible.  This was
one of the requirements since we didn't want to inconvenience developers
switching between debug/release builds.

The argument that the code segfaults when apr_palloc isn't able to
allocate any memory is moot.  Dean and others have indicated more
than once that memory allocators usually do lazy allocation, which
would result in segfaults in the code anyway because malloc never
returns NULL.

Given that, we could even opt for removing the abort callback function 
altogether.


Sander

Mime
View raw message