Re: the foreign c-string type: what animal is that?

> ;; when I reported the :in-out c-string GC bug (1996), CMU thought it was
> ;; dangerous anyway and disabled :in-out c-string combination.
> ;; We work around the problem by not using DEF-ALIEN-ROUTINE and call
> ;; the function directly.
>  ... (alien-funcall (extern-alien #) #)

Hmm, that seems similar to UFFI's foreign strings where you what to 
manually put the value in the string buffer and manual extract it. Of 
course, the low-level interface has that flexibility (and increased user 
work!)

> (malloc 'c-string "abc") does in fact two allocations:
> 1. one for the pointer, since char* IS a pointer
> 2. one for the buffer contents

True.

> This problem does not arise when allocating buffers directly:
> (malloc '(c-array character 13) "abcde...")
> like (malloc 'int -123456789)

So you create a lisp object that is the foreign object, and it's pointer 
is just the address of the object. Is that right?

> I had the following idea. A malloc with initialization doesn't allocate
> a c-string (pointer object) and a buffer. Instead, it creates a
> foreign-variable of type (:array character <N>) where <N> is computed
> dynamically as (1+ (length init)). But I don't like exceptions to
> otherwise regular schemes. And it cannot handle malloc without initarg.

Hmm, you can also do a malloc without initialization by passing it
the size. You can then pass the address of this buffer to a foreign 
function to get a return value.

Kevin