Discussion:
[Larceny-users] foreign-null-pointer not a void*?
Adam Smith
2008-11-10 02:51:08 UTC
Permalink
Currently void*? only checks if its parameter is a void* record. Since
foreign-null-pointer simply returns 0 - which is not a void* record -
the check fails, which makes it tricky to pass a NULL pointer to a C
function...should void*? be redefined as...

(define (void*? x)
(if (foreign-null-pointer? x)
#t
(record-predicate void*-rt)))

?
Felix Klock
2008-11-10 04:48:45 UTC
Permalink
Post by Adam Smith
Currently void*? only checks if its parameter is a void* record. Since
foreign-null-pointer simply returns 0 - which is not a void* record -
the check fails, which makes it tricky to pass a NULL pointer to a C
function...should void*? be redefined as...
(define (void*? x)
(if (foreign-null-pointer? x)
#t
(record-predicate void*-rt)))
?
When I added the void*-rt record type, I was attempting to catch
argument type mismatch bugs. I believe this was around the time that
I was working on a GTK+ interface via the FFI.

Many of the GTK+ functions did not work properly if passed null for a
pointer to a GTK object, so I deliberately decided that the void*-rt
and its subclasses would not accept 0 or #f as a marshallable value.

I believe I then added the (maybe _) type constructor to the FFI as a
way to handle the case where a function *did* accept or produce null
as an additional possibility added onto the pointer type.

My point: the strategy I suggest is for you to use
(maybe void*)
or more generally, (maybe T) where T is a record-subtype of void*-rt

I (once again) apologize that all of this is not included in the
Larceny documentation. (I'm not certain that this detail is even
documented properly in my Scheme Workshop 2008 paper on Larceny's FFI.)

-Felix

Continue reading on narkive:
Loading...