[cffi-devel] foreign-symbol-pointer weirdness

[Martin Simmons]

>>>>> On Tue, 11 Apr 2006 23:28:08 +0400, Samium Gromoff <_deepfire at 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 at mail.ru> said:
> > > Delivered-To: cffi-devel at 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