Subject: [clisp-list] Re: c-pointer: NULL == NIL polymorphism

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Tue Aug 5 02:17:04 2003

Hi FFI users,

>> Or allowing NIL for c-pointer (and return NIL for c-pointer 
>as NULL!),
>> as I said would be ok in last week's e-mail.
>Unless Bruno objects, I will make NIL a valid value for c-pointer and
>interpret it as a NULL pointer, and convert NULL to NIL on return.
>objections?

I believe users should be told the reasons instead of just asking for hypothetical objections.

A NULL<->NIL conversion when using C-POINTER acknowledges the fact that NULL *always* has a special meaning for a pointer type. So we consider it better (speaking of types) to return a "bottom" object of a different type (->NIL) than a foreign-pointer that would, a priori, allow dereferencing, causing a core dump.

The immediate advantage to users is that whenever a function requires a C-POINTER, it may often be NULL, in which case NIL will be accepted by CLISP, while in the past, something like (unsigned-foreign-address 0) or something similar had to be written.

The NIL->NULL change is compatible (unless you counted on your application to raise a type error). The NULL->NIL is not.

CLISP already supports NULL<->NIL for the following types: C-FUNCTION and C-ARRAY-PTR. I think we should clearly say so in the impnotes.

That does not mean that foreign-objects never point to 0 anymore. In fact,
(unsigned-foreign-address 0) still returns
#<FOREIGN-ADDRESS #x00000000>, not NIL.
Sorry, I hope this detail will not confuse you
 -- I sometimes believe I should say less.

Regards,
	Jorg Hohle.

---

From: Sam Steingold <[email-masked]>
Date: Tue Aug 5 07:24:05 2003

> * In message <[email-masked]>
> * On the subject of "Re: c-pointer: NULL == NIL polymorphism"
> * Sent on Tue, 5 Aug 2003 11:10:44 +0200
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>
good point.

> A NULL<->NIL conversion when using C-POINTER acknowledges the fact
> that NULL *always* has a special meaning for a pointer type.

Actually, IIUC, C does not know the difference between an array and a
pointer (as a function argument), so I don't really see why C-PTR and
C-ARRAY do not accept NULL (=NIL) and thus make C-PTR-NULL and
C-ARRAY-PTR necessary.

> #<FOREIGN-ADDRESS #x00000000>, not NIL.

Actually, it might be a good idea to go for consistency and make
(unsigned-foreign-address 0) return NIL.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Do not worry about which side your bread is buttered on: you eat BOTH sides.