[Openmcl-devel] Re: [Bug-openmcl] Apparent bug in the objc bridge

[Dan Knapp]

> Floating-point parameters to callbacks have dynamic extent (the boxed
> float that lisp sees is allocated on a stack, and returning a stack-
> allocated value generally returns garbage.)
>
> (The documentation of DEFCALLBACK does mention that foreign :ADDRESS
> args are stack-allocated, but should probably say something broader.
> I also think that making stack-allocation the default was probably a
> bad idea: DEFCALLBACK should probably obey explicit DYNAMIC-EXTENT
> declarations, but not introduce implicit ones behind the user's back
> ...)

   Yeah, it probably shouldn't be silent about that - at least a 
warning, if that
behaviour is going to stay.

   It took me a minute to understand what you were saying - it didn't 
make
sense that a function should stack-allocate something and then return 
it.
You're saying that the foreign callers pass in a pointer to where these 
things
are stored, which is typically space that they have already 
stack-allocated?
This is the same mechanism as used for structs, then?  Is it just 
structs and
floats that behave this way?

   Hm.  So what exactly is happening in my example, where Lisp calls 
Lisp?
I guess the "send" calls a foreign function belonging to the objc 
infrastructure,
which then calls the callback.  So, who allocated the memory?  Objc?  
But
it wouldn't do that for an ordinary call...

   Should this be handled like structs, where the return value is 
explicitly made
into an extra parameter?

   Not that I need to, but is there any way for an objc method 
implemented in
Lisp to return a float?

   As soon as I understand the full situation, I'll update the docs 
appropriately.

-- Dan Knapp