Re: FFI in Emacs

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 12 Mar 2013 23:53:28 +0100
> From: Aurélien Aptel <aurelien.aptel+emacs@gmail.com>
> Cc: joakim@verona.se, emacs-devel@gnu.org
> 
> On Tue, Mar 12, 2013 at 10:50 PM, Eli Zaretskii <eliz@gnu.org> 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.

Because each additional external library required to build Emacs is
more nuisance and complexity for end users, who need to find a
compatible version, install it, and know how to tell the compiler to
find it.

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

Daniel explained why it isn't strange.  Emacs on Windows does define a
separate heap, to emulate the Posix sbrk and its behavior, see
w32heap.c.

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

Again, Daniel explained that any function that opens a file and any
FILE object cannot be passed safely.