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
primitive types:

   A     address
   B     byte
   C     char
   I     int
   L     long
   D     double
   NIL   void


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.


A structure

   struct {
      int i[2];
      double d;
      char c[32];
   };

would be written as

   ((I . 2) D (C . 32))


A function call to allocate four of these structures:

   (setq
      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
primitive types.


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
not):

   (struct Stat Ptr '((3 4) 123000 "test"))

   (struct Stat Ptr) -> ((3 4) 123000 "test")


That all I have at the momen.

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Reply via email to