Subject: [clisp-list] FFI:mem-read and mem-write? -- a "good enough" topic

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Mon Apr 7 07:58:10 2003

Hi,

I've been thinking about adding a variant of the AFFI:MEM-READ and MEM-WRITE functions that I once put into my AFFI. They would help with some variable-length data.
They allow to read/write CLISP's specialized vectors.
See AFFI in your local impnotes or in:
http://clisp.cons.org/impnotes/affi.html

Pros:
+ Much current convoluted FFI code could become easier to read, write and interface to:
Instead of constructing variable-length type definitions at run-time
  (foreign-value (cast data `(C-ARRAY uint8 ,size)))
using MEM-READ, I'd have written (much like in Allegro):
  (let ((result (make-array size :element-type '(unsigned-byte 8))))
    (mem-read (foreign-address data) result))

+ Good enough (even much better than current FFI) for Aurelio's DB interface, zlib-compress and many more.

+ compared to FFI, no need for build+immediately destroy foreign-variable object and definition (->better performance).

+ never need to build&parse-C-type declaration at run-time (->performance).

Contra:
- By nature, MEM-READ/WRITE only operate on CLISP's specialised arrays.
That is (UNSIGNED-BYTE 8/16/32).
No SIGNED-BYTE arrays
No floating point arrays (somebody once asked for that).
- By nature, doesn't know about DEF-C-TYPE aliases.

I.e. they leave a feeling of "80% good enough", yet "not compatible with or stands in the way of 100% solution".

What's when the user wants to read an array of *signed* bytes?
(dotimes (i size)
    (setf (aref result i) (mem-read data 'sint8 i)))
looks less convincing than (FFI:OFFSET data `(c-array sint8 ,size)).

So what's the value of a limited function like MEM-READ?

The current FFI forms implement kind of 100% solutions: u/sint8/16/32/64 and even floating point.

So is it worth providing MEM-READ/VECTOR for FFI?

Regards,
	Jorg Hohle.