[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FFI in Emacs
Re: FFI in Emacs
Tue, 12 Mar 2013 23:53:28 +0100
On Tue, Mar 12, 2013 at 10:50 PM, Eli Zaretskii <address@hidden> wrote:
> Do we really need these libraries? If the Posix hosts can do with
> dlopen, dlsym, dlclose, and dlerror, then it's very easy to emulate
> that on platforms that don't have these in the system libraries. What
> else is needed, and why?
I agree that libltdl is small enough to be re-implemented but you
didn't say why you don't want to use it.
We could emulate it ourselves but libltdl is a small well maintained
library that already works on various systems.
This is even more true for libffi/fficall which handles architecture
specific stuff with raw assembler. Are the extra dependencies
>> a) a function can allocate memory that has to be freed
> At least on Windows, this cannot be done safely, so please don't
> design the interface based on the assumption this is doable. If a
> shared object allocates memory, it should be responsible for freeing
> it, or provide an API for telling it to free it.
I'm not sure I understand. You're saying that freeing a pointer
returned by a library function which explicitly says you have to free
it yourself is not safe on Windows? That seems strange.
Anyway this is not a fundamental part of the interface design, it's
just something that can happen to keep in mind.
> Likewise with file descriptors -- they cannot be safely shared across
> the interface, because the shared library could have used a different
> runtime for opening files.
If you're talking about read(), it was just an example of a
problematic API (side effects). If you're writing some code to
interface with C I expect you to know what you're doing.