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

[Gary Byers]

On Wed, 10 Nov 2004, Dan Knapp wrote:

> > 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?

Sorry; I didn't look at the original bug report carefully enough.
Some parameters to callbacks do get stack allocated (and that's
a questionable idea and a common source of confusion, but doesn't
seem to be relevant here.)  I misread the test case as returning
a floating-point argument, and that would fail for reasons similar
to the failure you'd get on:

(defun foo (&rest args)
  (declare (dynamic-extent args))
  args)

Only it's a little weirder, because DEFCALLBACK is introducing
DYNAMIC-EXTENT declarations.


But that has little to do with the problem that you reported.
>
>    Not that I need to, but is there any way for an objc method
> implemented in
> Lisp to return a float?
>

There should be, but there are bugs in the implementation. DEFCALLBACK
has to handle floating-point return values differently under Darwin,
and the lisp kernel code that mediates between the foreign code and
the lisp callback also has to handle any potential floating-point
return values differently.  (The garbage value that's being returned
is "whatever's in the F1 register when the callback returns", and
things are a little confused about how to get 1.2 into the F1 register.)