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 ())_. [EMAIL PROTECTED],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