[Openmcl-devel] Re: [Bug-openmcl] Apparent bug in the objc bridge
dankna at accela.net
Wed Nov 10 17:21:40 EST 2004
> 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
sense that a function should stack-allocate something and then return
You're saying that the foreign callers pass in a pointer to where these
are stored, which is typically space that they have already
This is the same mechanism as used for structs, then? Is it just
floats that behave this way?
Hm. So what exactly is happening in my example, where Lisp calls
I guess the "send" calls a foreign function belonging to the objc
which then calls the callback. So, who allocated the memory? Objc?
it wouldn't do that for an ordinary call...
Should this be handled like structs, where the return value is
into an extra parameter?
Not that I need to, but is there any way for an objc method
Lisp to return a float?
As soon as I understand the full situation, I'll update the docs
-- Dan Knapp
More information about the Openmcl-devel