Re: DSO-style DSOs (this is NOT an FFI!)

["Stephen J. Turnbull" <stephen@xemacs.org>]

Ted Zlatanov writes:

 > DH> As for accidental corruption, you can at least protect your Lisp_Objects
 > DH> by controlling how you copy data into and out of them.

DSOs are no different from any other C code as far as data corruption
goes.  You can't do anything more, and shouldn't do less, than you
could do if the code were linked into Emacs at build time.  The advice
is "be a good Emacs C-level programmer, and you'll be OK."

The only reasonable restrictions are:

(1) Initialize the module with

    if (this_module_max_gpl < this_emacs_min_gpl) launch_lawyers();

(if this_module_max_gpl is undefined, the link will fail, which is the
desired outcome :-).

(2)  callbacks into Emacs must refer to symbols obtained from
     intern().  You can't call extern functions or reference extern
     variables directly.

The marshalling and unmarshalling implied by (2) needs to be done
anyway because these DSOs are intended to provide Lisp-level
functionality.  (If not, there's no problem.  Ask Eli Z about how
Windows does its "if-available" DLL loading.)  It may as well be done
in the DSO so that intern() is the only rendezvous point needed
between Emacs and the DSO.

 > Moreover, I was wondering whether the risk is acceptable.

If it's not, the implications for using any Emacs coded in C are,
well, *severe*. ;-)  (The "maybe we're loading non-GPL 3d-party code
unknowingly" risk is an exception, of course.  That's irrelevant to
language though -- I've always wondered why non-GPL DSOs are a risk
and non-GPL Lisp isn't.  But let's not go there.... :-)

 > The other extreme is to have some protocol to externally executed
 > modules so there's no chance of corruption; it's very inefficient
 > but also much less risky.

That may as well be a true FFI (ie, a way to bind Lisp symbols to
external objects from Lisp).  If it's not, then the module programmer
is writing C, so: GOTO "DSOs are no different...."[1]

Footnotes: 
[1]  Emacs programmers are hardly exempt from the dictum "premature
optimization is the root of all error".  The temptation to short cut
the protocol when writing C will be unbearable for some.