Roger Corman said on the topic of name mangling (back in 2003), aka. =
>You could try to make it easier by doing his automatically, but you =
>in general know what name mangling scheme was used (if any was used). =
>may have been generated by different compilers. In Corman Lisp FFI I =
>it and let the user worry about it. If they call a mangled name, they =
>to explicitly specify that name. Nobody has complained, probably =
>most exported functions do not have mangled names (if they support a C
>The Microsoft C++ compiler automatically does the name mangling unless =
you tell it otherwise.
>This is to catch problems (incorrect declarations) at link time rather =
than run time.
>However, you can disable it when you build (link) a DLL by including a =
>with the names explicitly listed.=20
>Microsoft does this for all their system DLLs. The names are not =
Uhoh, it means there are libraries around with mangled names and others =
I bet this kills portable-among-implementations packages like cl-gd, =
unless it uses some macros like (with-name-mangling-of-type foo do...)
Roger also writes:
>Sometimes if you use the wrong linkage you won't notice, because (a) =
>there are no parameters it makes no difference (b) even if there are
>parameters, usually exiting a function cleans up the stack properly. =
>something is linked with __cdecl (C conventions) and you call it with
>__stdcall, nobody cleans the stack. This might work, as long as you
>don't do it in a big loop, and you don't embed the call in another =
>i.e. foo(bar(x, y), z).
I think it means that one should not see problems with it in CLISP -- =
except when callbacks are involved, where the foreign land will be =
responsible for cleaning the stack. For direct calls, stack clean up at =
exit of clisp' invoke-foreign-function() function will prevent both the =
loop accumulation or embeded scenarios, since clisp does not compile to =
So what's left:
- stdcall is the correct declaration for bgd.dll, according to =
- for FFI purposes, that library would have been more useful as cdecl.
- remove the "@" check code from def-call-out. @ is acceptable in the =
C names, at least on MS-Windows.
- let users handle name mangling or
- still try to provide some generic rule, so that packages like cl-gd =
can be written with some hope for portability??