AW: Alternative to copy-in/copy-out?

Liam M. Healy wrote:
>Here's how I would implement a direct call in ACL:
>
>(ff:def-foreign-call (half-double-vector "half_double_vector")
>    ((size :int)
>     (vec (:array :double)))
>  :returning :void)

Actually, I very much prefer FFI declarations which provide more information than Allegro does. What is extremely important for this example to work, is that the double array is passed *read-write*. This is not natural (yet typical for C). Having means to express this difference helps a lot in portability, maintenance and program understanding.

The above declaration would not work in a world where a copy of the array would be passed (for whatever reasons, e.g. additional zero-terminator for strings, different representation, etc.).

What's needed is a high level means portable to both scenarios:

(def-f-f-c (half-double-vector "half_double_vector")
  (size :int [pass by value])
  (vec (:array :double) :destructive [by default :input])
  :returning :void)

In case :destructive was used, UFFI would have half-double-vector be a closure in CMUCL, CLISP or others doing:
(lambda (size vec)
  (multiple-value-bind (output-vec)
      (actual-ffi-call "half_double_vector" size vec)
    (fix-in-place output-vec vec))) ; e.g. FILL or similar

On Allegro, half-double-vector would be a direct call to the foreign function, since the :destructive wrapper is not needed.

I have a vague idea to distinguish ':destructive' from a ':io' declaration, because on CMUCL and CLISP, there could be less copying. :io in these implementations doesn't mean "fix in place". They still pass a copy of the array, and return the updated array as an extra value (that's why I used multiple-value-bind). This is farther away from C, but closer to IDL/DCOM.


The only advantage of the Allegro Scheme is that it can be generated automatically from C header files. .h has no information about :read-only, :fix-in-place etc.
Interface Description Languages (IDL) are much more precise in their semantics. It would be a shame that a UFFI be adequate only for C style - read incomplete - declarations.

Regards,
	Jorg Hohle.
who's working on reliability/dependability of software