Re: rename troublesome ltdl apis [libtool--devo--1.0--patch-275]

[Gary V. Vaughan]

Hallo Ralf,

Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Sat, Sep 17, 2005 at 10:05:48PM CEST:
>>      * libltdl/ltdl.c (lt_dlcaller_register, lt_dlcaller_set_data)
>>      (lt_dlcaller_get_data): Renamed to avoid problems with module
>>      visibilty when linked with programs written for the old API.
>>      compatible zero argument version, adding a deprecation warning.
>>      (lt_dlinterface_register, lt_dlinterface_set_data)
>>      (lt_dlinterface_get_data): New names.
>>      * Makefile.am (VERSION_INFO): Bumped.
>>      * doc/libtool.texi (User defined module data): Updated.
> 
> I don't understand why now you start to rename _all_ of that stuff, and
> not only the troubling lt_dlcaller_register.

For exactly the same reasons as with lt_dlcaller_register.  It all
follows on quite logically -

  i) lt_dlcaller_id was declared as an unsigned int in old ltdl.h,
     but lt_dlinterface_register no longer returns an unsigned int,
     but an opaque void*.  To prevent difficult bugs with platforms
     that have different sized void* and unsigned especially, but
     also regular users to some extent we need to rename lt_caller_id
     to lt_dlinterface_id.

 ii) Now, lt_dlcaller_{g,s}et_data each take an argument of a different
     type than before (void * vs unsigned) and rather than relying on
     just the compiler's type checking by your argument for renaming
     lt_dlcaller_register, these functions too need renaming.

> This places an undue
> burden on innocent users that never deal with more than one module
> loader.  Those would otherwise be fine with just adapting their call of
> lt_dlcaller_register.

There are no such users with libtool-2.0, as libltdl itself has modules
in the handles list which (like all modules) should be protected from
other clients (hence my patch-277).  In order to do that, lt_dlcaller_id
needs to be richer than an unsigned, and the rest follows as explained
above.  Assuming popular libraries take advantage of 2.0 libltdl module
loading, inevitably some ltdl module loading libraries can have no clue
as to whether their client application, or other libraries that client
uses will be adding modules to the internal ltdl handle list, and we
need to make it as robust as possible for each client to not worry about
modules loaded by the others... lt_dlinterface_id was the mechanism I
invented for this purpose, but failed to follow through to the rest of
the libltdl API until now.

> There is no need to keep users from shooting themselves in the foot, if
> they ignore documentation.
>
> Am I missing something again?

Only the same arguments we both put forth for changing the name of
lt_dlcaller_register -- forced to change function footprint to avoid
problems with other clients' modules, which in turn suggests a good
reason to rename said functions to force a hard compilation failure if
the user doesn't upgrade the caller's semantics to match the new APIs.

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature