On Tue, Oct 21, 2008 at 09:20:30AM +1100, konrad Zielinski wrote:
> THe interesting thing will be handling C structs. As almost every
> interesting C API makes heavy use of them.
Well, you know, I don't want to discuss such things prematurely. But as
you insist ... ;-)
Consulting my last year's notes, I think I had something like the
following in mind:
There is a function
(native "fun" "lib" <ret> <val> ..)
Actually, I don't like the name 'native'. Would prefer something
shorter. Perhaps just 'c' or 'C'?
"fun" is the name of a symbol in the library "lib". It is located with
dlopen() and dlsym() as before.
<ret> and the <val>s specify the return value, followed by the
arguments. These structures are interpreted by 'native', building up
appropriate data structures.
C structures are defined as nested lists. I thought of the following
An uninitialized character array of 8 characters would be
(C . 8)
while an array of 8 zero characters is
(C 0 0 0 0 0 0 0 0)
That is, an atomic CDR is a size spec, while a list contains
one or more initializers.
would be written as
((I . 2) D (C . 32))
A function call to allocate four of these structures:
Stat '((I . 2) D (C . 32))
Ptr (native "malloc" "libc.so" A (I (* 4 (sizeof Stat)))) )
So 'native' knows that it has to return a pointer 'A', and to pass a
single integer with the value (* 4 (sizeof Stat)) to 'malloc'.
'sizeof' is system dependent, knowing of the sizes of individual
Then we have a function 'struct' which takes a structure specification
and a memory pointer, and either stores an s-expression in memory (if a
third argument is given), or builds an s-expression from memory (if
(struct Stat Ptr '((3 4) 123000 "test"))
(struct Stat Ptr) -> ((3 4) 123000 "test")
That all I have at the momen.
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]