apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apu_dso_load and errors
Date Sat, 06 Sep 2008 18:18:41 GMT
Graham Leggett wrote:
> Hi all,
> 
> The current dso helper code in apr-util masks the apr_dso_handle_t 
> structure from the caller, and in the process makes it impossible to 
> call apr_dso_error to find the human readable error message for why the 
> module failed to load.
> 
> The attached patch fixes this, making a change to the 
> include/private/apu_internal.h header file to expose the 
> apr_dso_handle_t structure.
> 
> The plan is to commit this to trunk only (1.4.x and later) - given that 
> the header is private, does this break the ABI rules?

The ABI rules generally allow internal changes.

However, -1 to this patch, as it is a private function and you haven't
actually demonstrated a use case.  This implies you are relying on it
externally which defeats the 'private' declaration.

Likewise, the module handle is private.

apu_dso_load is transparent to the user.  If misconfigured, the caller
(e.g. mod_ldap/mod_db[dm] caller) is clueless that this might have
happened.  I suggest proposing a specific API for dealing with the
public aspects of apu_dso_load, and have both functions return some
"special case" error code for this purpose, which maps to the most
recent error result of apu_dso_load.



Mime
View raw message