lt_dlcaller_set_data interface question

[Eric Blake]

I ran into the following situation when trying to enhance m4:

lt_dlhandle handle = ...;
if (initfn = (initfn_t) lt_dlsym(INITFN, handle))
  initfn();
if (lt_dlcaller_set_data (id, handle, new_value) == 0
    && (str = lt_dlerror()))
  error (0,0,"unable to change dlcaller data: %s", str);

Unfortunately, the error() tripped any time that the module did not provide an 
optional initfn entry point, and the previous data value was 0 (since for 
lt_dlcaller_set_data the return value 0 is ambiguous between a valid previous 
value and an error indicator).  Further analysis shows that when a symbol is 
not present, lt_dlsym sets lt_dlerror to "symbol not found", but 
lt_dlcaller_set_data does not reset this string.  Then, because I followed the 
documentation that said to check lt_dlerror if lt_dlcaller_set_data returns 
NULL, and because the string was not reset, the code reports failure even 
though the data was correctly set.

Ultimately, this boils down to an interface question of what should happen if 
prior errors are ignored:

Is this a bug in m4, for not calling lt_dlerror to clear errors after any time 
lt_dlsym returns NULL?  The design for m4 modules is that there are four 
optional entry points, and the module is acceptable if at least one of the four 
is provided (most modules will return NULL for lt_dlsym for at least one of the 
four, and thus trigger lt_dlerror).  The current m4 code calls lt_dlsym in 
numerous places without clearing lt_dlerror when an optional symbol is not 
found, such as in the lt_dlinterface_id callback.  Also, the documentation for 
lt_dlinterface_interface does not mention anything about whether the callback 
function is required to reset lt_dlerror, or if it can leave it in an unknown 
state.

Or is it a bug in libtool, for not resetting all prior errors on entry to 
lt_dlcaller_set_data?  In other words, should each libtool function start with 
a clean state, regardless of whether the user failed to call lt_dlerror to 
clear out errors from a previous lt_* call?  And likewise, when libtool calls 
the lt_dlinterface_id callback, should it be clearing out any lt_dlerror 
leftovers generated during the callback?

And for this particular case, there is a third option:

Maybe it is worth an interface change in the case of lt_dlcaller_set_data?  For 
example, int lt_dlcaller_set_data2(lt_dlinterface_id, lt_dlhandle, 
void*new_data, void**old_data); where old_data, if not NULL, is set to the 
prior value, and the return value is unambiguous (0 for success, nonzero for 
failure)?  That way, regardless of whether I ignore prior errors, there is no 
longer an ambiguity between success and failure, so I no longer need to call 
lt_dlerror when I know the function succeeded.

-- 
Eric Blake