[clisp-list] Re: Linkkit breakage in 2.31.

[Kaz K. <ka...@as...>]

On Fri, 5 Dec 2003, Sam Steingold wrote:

> > Secondly, the FFI translator puts out ill-formed C, so even if you
> > work around the first problem you run into others.
> 
> see NEWS:
> 
> * FFI does not output extern variable and function declarations unless
>   you set FFI:*OUTPUT-C-VARIABLES* and/or FFI:*OUTPUT-C-FUNCTIONS* to T.
>   Please use FFI:C-LINES to include the appropriate headers instead.
>   See <http://clisp.cons.org/impnotes.html#ffi-extern-output> for details.
> 
> the rationale is that there is no way to reliably output extern
> declaration that would be compatible with the system headers (which
> should be included anyway!), so why not rely the headers instead?

This is a silly rationale, because all that is done with the declared
functions is to take their address and cast it to (void *). The functions
are not actually called in the generated C module, so the type signature
does not come into question.  The declarations, effectively, merely
assert the existence of these functions as entry points in the address
space.  Thus it buys you nothing that the declarations come from a more
legitimate source. It would matter in some fictitious C implementation
whose function pointers carry type information that is preserved under
pointer casts and checked at call time.

Moreover, you can include all the right headers, yet completely lie in
the DEF-CALL-OUT form to generate an incompatible call. The C compiler
won't squawk at all!

For error checking, the most useful behavior would be to have both:
enable the generation of function declarations *and* use C-LINES to
include the headers. This way the FFI-generated declarations could be
type checked against the original declarations from the external headers.
The C compiler would catch, say, the Lisp side using ``int'' for
a mode_t parameter which is typedef'd to ``long'' in the system header.

The way it is, the new behavior is just a misfeature that breaks existing
projects based on CLISP. Their users cannot independently upgrade CLISP
without obtaining fixed versions of these projects. I'm not saying that
backward compatibility is some supreme value that must be preserved at any
cost, only that it should be broken when there is no other reasonable
way to fix some actual problem.