From: Kaz K. <ka...@as...> - 2003-01-15 20:03:35
|
CLISP contains a foreign function and foreign variable registry keyed on symbol name, which forbids duplicate registration. If you happen to have two FFI modules in your image which try to target the same library function, you get a nasty error, such as: *** - A foreign function "strerror" already exists 1. Break [2]> This is a problem because you have to write your own wrappers for every library function to ensure it has a unique name, or else risk clashing with other pwople's modules that you don't even know about. Or you can use some GNU toolchain extensions to create symbol aliases, if you don't want wrappers, but that's still annoying. It would be nice if the foreign function hash table was keyed on something other in addition to the name, like maybe it could be an #'equal table keyed on (list function-name package-name), and some way to specify the that second element could be worked into the def-call-* macros. Or they could implicitly pick it up from the current *package*, even. This seems like a bit of work, because it affects what goes into the .c file generated from the FFI .lisp module. E.g. this: void module__unix__init_function_2(module) var module_t* module; { register_foreign_function(&strerror,"strerror",1024); /*...*/ } has to become this: void module__unix__init_function_2(module) var module_t* module; { register_foreign_function(&strerror,"strerror","MYPACKAGE",1024); /*...*/ } And of course register_foreign_function and register_foreign_variable have to be changed and every place that refers to the hash table and so forth. Any other ideas? What if, quite simply, duplicate registrations were silently permitted? What would break? |