[clisp-list] Strangeness involving FFI pointers and ext:saveimage.

[Kaz K. <ka...@as...>]

Some CLISP code of mine was crashing, but only when run from a loaded
memory image, not when loaded directly as .lisp or .fas files.

It turns out that it was failing to detect a null pointer coming out
of a glibc2 function (I'm using a CLISP built using
--with-modules=bindings/linuxlibc6). And so it then passed the
null pointer to the library, which tries to dereference a structure
member in it, causing a fault at address 0x10.

My program tries to capture a null pointer by doing this
ugly hack:

(defconstant *null-pointer* (linux:realloc (linux:malloc 1) 0))

This gives you an object which prints like this:

    #<FOREIGN-ADDRESS #x00000000>

It compares positively to other such null pointers under
the EQUALP function, so you can use it, for instance, to detect
linux:readdir returning NULL.

Now here is the rub. After having defined *null-pointer*, if
you save the memory image with ext:saveinitmem, and then
reload, the value of *null-pointer* now prints like this:

    #<INVALID FOREIGN-ADDRESS #x00000000>

     ^^^^^^^^

This object no longer compares EQUALP to newly computed null pointers.
Something in its representation has changed on save and reload, which
is disturbing.

I'd like to know what the recommended way is to test for
null pointers coming out of the FFI. Should I convert
#<... #x00000000> to a string and parse out the hex or what? 
Or compile in a C function to do it?

For now I have a workaround, which is to make *null-pointer* a
variable, and setf a new value to it right after loading the memory
image.