Subject: [clisp-list] RESOLVED: FFI question: returning array of "C" struc ts

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Wed Aug 7 05:09:02 2002

Hi,

John K. Hinsdale wrote:

>I would advise against returning an array of whole structs to CLISP in
>any situation.
Why? Esp. Why do you seem to reject a return-type of e.g.
(c-ptr (c-array mystruct 100)) but accept
(c-array (c-ptr mystruct) 100) or
(c-ptr (c-array (c-ptr mystruct) 100)) ?

>I have to say I strongly disagree w/ the convention of imposing a
>special meaning (i.e., terminator) on "all zero byte" structures.
>There would be too many applications where all-zero data was a valid
>representation.  Mine isn't one of them, but I have the suspicion I'm
>just lucky.
I never said that zero-terminated arrays were great. They have uses. And in the pityful situation of the CLISP FFI, one is lead to consider whether the set of possible (acceptable) uses shouldn't be stretched somewhat.

>All this becomes moot when the array consists only of pointers, plus a
>null-pointer terminator, and that is why I recommend the pointer-array
>approach.
I mean, I don't grasp the difference you make for pointers.
Zero-termination for arrays of pointers may work no better than for structures. NULL is a legal value for any pointer in the array. It's completely application dependent whether this can be interpreted as an "end-of-array" marker.

E.g., the regexp-match could return an array of N pointers to subgroups, NULL therein meaning "this regexp subgroup () was not matched", as in "(http://)?([-a-z0-9\.]+)?"
matching "abc.def/" should return [NULL, "abc.def"].

>OK, but to be honest, what I'm trying to do is just get this to work,
>hopefully w/out bugs and leaks, and then get the hell out of "C" and
>into Lisp as soon as possible!
This is why working on a possibly high-level FFI is not rewarding at all. It seems people can be more easily satisfied with a C-level (i.e. low) interface which grants them all the freedom and possibilites they can think of, at the price of doing, as in C, memory management, transformations etc. on their own.
I tend to see the failure of what in Ada is called thick bindings (well-integrated into language, better?) vs. thin (low-level, worse?) bindings to a foreign library.

Regards,
	Jorg Hohle.

---

From: "John K. Hinsdale" <[email-masked]>
Date: Wed Aug 7 09:55:03 2002

>> [J. Hinsdale]

 > I never said that zero-terminated arrays were great. They have
 > uses. And in the pityful situation of the CLISP FFI, one is lead to
 > consider whether the set of possible (acceptable) uses shouldn't be
 > stretched somewhat.

I guess in cases where the application allows for it, would be OK (and
in fact it work for my database struct).  In may case, the struct has
a bunch of integers (for which zero is a valid value that can and will
occur as part of normal operation, and some pointers to data, which as
it turns out will always be non-null, but that is just coincidence.
In my app, it's not farfetched to assume that one day the
representation would change so that those pointers could be null (say
to represent the SQL "null" value, which for now I am using a separate
flag).  that would then break the interface.  If you used the struct
pointers, then you can have any arbitrary data, but as you pointed out
you have to be careful that each and every pointer is non-null except
the last.  There does have to be some sort of application-specific
convention.