[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: [Gcl-devel] puzzled....

From: Camm Maguire
Subject: [Axiom-developer] Re: [Gcl-devel] puzzled....
Date: 28 Apr 2004 18:56:50 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


root <address@hidden> writes:

> in o/object.h (line 350) there is the struct:
> struct ustring{ 
>   ....
>   unsigned char *ust_self;
>   ....
> this appears to be the definition of ust_self, a pointer to a char *array
> in gcl-tk/sheader.h (line 109) OBJ_TO_CONNECTION_STATE(x) is defined as
>   ((struct connection_state *)(void *)((x)->ust.ust_self))
> so it appears that OBJ_TO_CONNECTION_STATE accepts a thing of type
> ustring and casts the (char *)array to a (connection_state *)array
> yet in sockets.c (line 330) the macro is used with an argument:
>  .... (OBJ_TO_CONNECTION_STATE(fd) .....
> where "fd" has been used to indicate the "file descriptor" which
> is a fixnum.
> Further the buffer it tries to write into needs to be of type ustring.
> I have 2 questions:
>   (a) should sockets.c line 330 read:
>        ... (OBJ_TO_CONNECTION_STATE(sfd) ...
>        (which means that the argument to the function must change)

I don't think so.  If you look at the arguments to
OUR-READ-WITH-OFFSET, fd is a lisp object, as poor as variable name
choice as that is.  A 'file descriptor' would be of type fixnum.

>   (b) how does one allocate a ustring?

Your original make-array will do.  If you notice GCL's object layout,
compatible _self pointer elements are aligned in the same position in
the various structs, so that in indirecting the lisp union, one can
use st_self, ust_self, v_self, etc.

Also forgot to answer your question put in the other email --
fSour_read_with_offset is created by the expansion of the DEFUN_NEW C
macro.  If one runs cpp -I../h -I../gcl-tk on sockets.c, you'll see
the definition.  Basically one gets a generic lisp interface, and a
raw C interface which can be used directly in 'fast-linking'.

BTW, your first example call to our-read-with-offset appeared to be
correct at least regarding the caar, as the 'connection state' is 48
bytes long and is passed around in lisp as a string of the same
length, which is correctly passed into fSour_read_with_offset in your

We have to figure out what the 'magic' is all about.

I'll try to drum up a simple socket example if I can find a moment.
I'm wondering right now if what we have was designed purely for

Take care,

> Tim
> _______________________________________________
> Gcl-devel mailing list
> address@hidden

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]