[clisp-list] Re: Problem when C function targetted twice by FFI modules.

[Kaz K. <ka...@as...>]

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?