#401 Invalid null pointer in a saved image
When loading an image where a variable was set to a null foreign pointer, like:
(defvar null-ptr (ffi:unsigned-foreign-address 0))
access to null-ptr returns an invalid foreign pointer, instead of valid (as it was before the image was saved and stopped). Here's a sample code that demonstrates this problem:
,-----
| (asdf:operate 'asdf:load-op 'cffi)
| (asdf:operate 'asdf:load-op 'cffi-uffi-compat)
| (defvar my-null-ptr (ffi:unsigned-foreign-address 0))
| (format t "- Before loading image, null ptr is: ~A!~%" my-null-ptr)
| (ext:saveinitmem "test.exe"
| :init-function #'(lambda ()
| (format t "- After loading image, my-null-ptr yelds: ~A.~%"
my-null-ptr)
| (ext:quit))
| :NORC t
| :script t
| :executable t
| :quiet t)
`-----
The output I get when I run this code is (after the initial load messages),
,-----
| (...)
| - Before loading image, null ptr is: #<FOREIGN-ADDRESS #x00000000>!
| C:\dev\test>test
| test
| - After loading image, my-null-ptr yelds: #<INVALID FOREIGN-ADDRESS
#x00000000>.
`-----
I believe there's no point in making such null references invalid, and it breaks several code using foreign functions.
Logged In: YES
user_id=5735
Originator: NO
This is a feature, not a bug: why should we treat NULL pointers differently from all others?
What do you need this NULL-PTR variable for?
Logged In: YES
user_id=5735
Originator: NO
This bug report is now marked as "pending"/"invalid".
This means that we think that the problem you report
is not a problem with CLISP.
Unless you - the reporter - act within 2 weeks,
the bug will be permanently closed.
Sorry about the inconvenience -
we hope your silence means that
you agree that this is not a bug in CLISP.
Logged In: YES
user_id=816366
Originator: YES
Well, I was trying to load clqsl in clisp, and it uses such a variable to either make some comparisons or to pass as (null) arguments to foreign functions. I guess it should be cheaper than having to call a function every time we need a null pointer.
I understand why all other pointers are invalidated, but a null pointer is, and always will be, a set of zeros, so I don't see a point in making them invalid. However, if this is clisp's policy (historic reasons or others), I understand, and I'll ask clsql dev team to adapt to this issue.
Logged In: YES
user_id=816366
Originator: YES
this is the standard request for more information.
1. what is your platform?
("uname -a" on a Unix system)
compiler version? libc (on Linux)?
2. where did you get the sources? when?
(absolute dates are prefered over the relative ones)
3. how did you build CLISP? (what command, options &c)
please do a clean build (remove your build directory and
build CLISP with "./configure --build build" or at least
do a "make distclean" before "make")
4. if you are using pre-built binaries, the problem is likely
to be in the incompatibilities between the platform on which
the binary was built and yours;
please try compiling the sources.
5. what is the output of (lisp-implementation-version)?
6. what is the value of *features*?
7. please supply the full output (copy and paste)
of all the error messages.
If you cannot build CLISP, you can obviously skip 5 and 6,
but then you should provide more information in 1.
please see <http://clisp.cons.org/clisp.html#bugs>
for more information.
Thanks.
PS. This bug report is now marked "pending"
and will auto-close unless you respond
(in which case it will auto-re-open).
Logged In: YES
user_id=5735
Originator: NO
> it uses such a variable to either make some comparisons
(FFI:FOREIGN-ADDRESS-NULL foreign-entity)
This predicate returns T if the foreign-entity refers to the NULL address (and thus foreign-entity should probably not be passed to most foreign functions).
http://clisp.podval.org/impnotes/dffi.html#fa-null
> to pass as (null) arguments to foreign functions.
use NIL - it is auto-converted to NULL.
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).