[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FFI in Emacs

From: Aurélien Aptel
Subject: Re: FFI in Emacs
Date: 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
bothering you?

>> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]