[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FFI in Emacs
From: |
Eli Zaretskii |
Subject: |
Re: FFI in Emacs |
Date: |
Wed, 13 Mar 2013 05:55:49 +0200 |
> Date: Tue, 12 Mar 2013 23:53:28 +0100
> From: Aurélien Aptel <address@hidden>
> Cc: address@hidden, address@hidden
>
> 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.
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.