[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FFI questions
Joerg Hoehle has a very interesting question:
> I find it "good" (and fitting the Lisp paradigma) that a call to a C
> functions that returns a string returns either a (LISP-)string or
> NIL. Example: getenv().
Agreed. This was done because the C type "char*" actually means
"either NULL or a pointer to a sequence of characters". The Lisp equivalent
of this is the type (or null string).
> Shall a function that
> returns an opaque pointer return NIL or the integer 0 for C-NULL?
By definition, "opaque" means no conversion. CLISP boxes the pointer,
that's all. It never looks at the value of the pointer.
> Should programming effort come into consideration? As an example, I find
> (let (window)
> (unwind-protect
> (progn (setq window (openwindow 0-or-NIL? taglist))
> (when window
> ...))
> (when window (closewindow window))))
> easier to write and read ...
Agreed. Of course you can write a predicate `null-pointer-p', for example
like this:
int foreign_null_p (pointer)
void* pointer;
{ return (pointer == (void*)0); }
(def-c-call-out null-pointer-p (:name "foreign_null_p")
(:arguments (pointer c-pointer))
(:return-type boolean)
)
or by using EQUALP with a previously defined boxed NULL pointer.
In general, this is the way to go, because you will want more than
to look whether the pointer is NULL; for example, you may want to access
fields of the structure pointed to.
If you really want a special kind of argument and result converter for
nearly-opaque pointers, where the only conversion is for NULL, it is easy
to introduce a new converter, say C-POINTER-OR-NULL, similar to C-POINTER.
> Won't a NIL return affect portability for functions like sprintf()
> which on some systems return the number of characters written and on
> other return a buffer address because you don't know the prototype and
> thus don't know whether 0 or NIL might be returned?
To be portable, you have to specify the return type of sprintf() as
NIL (means "void") anyway.
Bruno Haible email: <haible@ilog.fr>
Software Engineer phone: +33-1-49083585
- References:
- FFI questions
- From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle)