Re: apu_dso_load and errors

[William A. Rowe, Jr.]

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.