[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lt_dlcaller_set_data interface question
From: |
Eric Blake |
Subject: |
lt_dlcaller_set_data interface question |
Date: |
Wed, 5 Sep 2007 18:18:17 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
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
- lt_dlcaller_set_data interface question,
Eric Blake <=