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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
