[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] puzzled....
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] puzzled.... |
Date: |
28 Apr 2004 18:56:50 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings!
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
>
> #define OBJ_TO_CONNECTION_STATE(x) \
> ((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
example.
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
gcl-tk.
Take care,
>
> Tim
>
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah