On Tue, 11 Apr 2006 23:28:08 +0400, Samium Gromoff _deepfire@mail.ru said:
On Tue, 2006-04-11 at 10:30 +0100, Martin Simmons wrote:
> On Tue, 11 Apr 2006 02:42:19 +0400, Samium Gromoff _deepfire@mail.ru said:
Delivered-To: cffi-devel@common-lisp.net
On Tue, 2006-04-11 at 01:55 +0400, Samium Gromoff wrote:
here is the scenario:
[snip]
(let ((foreign-ptr (foreign-symbol-pointer "verse_send_connect_accept" :code))) (format t "foreign-ptr contents: ") (dotimes (i 16) (format t "~2,'0X " (the (unsigned-byte 8) (mem-ref foreign-ptr :uint8 i)))) (format t "~%"))
This code gives different printouts on CLISP/CMUCL/SBCL backends:
CLISP: foreign-ptr contents: 55 89 E5 83 EC 28 8B 45 0C 89 44 24 04 8D 45 F8 CMUCL: foreign-ptr contents: E9 26 AE C3 F9 90 00 00 00 00 00 00 00 00 00 00 SBCL: foreign-ptr contents: E9 CE A2 A1 47 90 00 00 00 00 00 00 00 00 00 00
This amounts to foreign-symbol-pointer finding different things on different lisps, in the same shared library.
Luis Olivera suggested using (foreign-symbol-pointer ... :data) instead of (foreign-symbol-pointer ... :code), and it worked just fine, now providing pointers to exactly same code!
Apparently in the CMU/SBCL case i`ve been fed pointers to proc linkage table entries or some lisp-specific trampolines.
Is there any problem with getting different code? Using :data for code is not portable.
Indeed -- sometimes the C code wants to be fed back pointers to its own functions. As markers for setting up callbacks, for example.
Also, i guess, the principle of least astonishment is applicable here -- that is, a pointer to the function is a pointer to the function, after all.
OK, I see. Beware that on some OSes, functions can have an internal entrypoint and multiple external entrypoints, so different modules can see different pointers to the same function even in C code. This should be OK for function pointer comparison as long as the the old and new values are read by the same module.
__Martin