On 17 Apr 2024, at 08:07, Ruediger Pluem <rpl...@apache.org> wrote: >> Modified: apr/apr/trunk/util-misc/apu_dso.c >> URL: >> http://svn.apache.org/viewvc/apr/apr/trunk/util-misc/apu_dso.c?rev=1917050&r1=1917049&r2=1917050&view=diff >> ============================================================================== >> --- apr/apr/trunk/util-misc/apu_dso.c (original) >> +++ apr/apr/trunk/util-misc/apu_dso.c Tue Apr 16 21:33:58 2024 >> @@ -131,7 +131,8 @@ apr_status_t apu_dso_load(apr_dso_handle >> apr_dso_handle_sym_t *dsoptr, >> const char *module, >> const char *modsym, >> - apr_pool_t *pool) >> + apr_pool_t *pool, >> + apu_err_t *err) > > Now the caller needs to allocate memory even if it is not interested in the > error or if there is no error at all. > Wouldn't it be better to add an apu_err_t **err instead (which can be NULL) > and in case of an error allocate an > apu_err_t from pool and fill it and return it in **err (provided it was not > NULL).
I originally used this pattern and found it overkill - what I do now is allocate a app_err_t on the stack and immediately abandon it. In this particular case we need to always handle this error. I've had cases where I've brought httpd up onto a debugger to find out why I was getting incomprehensible failures elsewhere with no explanation, only to discover that it was as simple as the RPM containing the individual APR driver wasn't installed. What I can do is if(err) { ... } for the allocations. Regards, Graham --