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
