[Openmcl-devel] Re: [Bug-openmcl] Apparent bug in the objc bridge
gb at clozure.com
Wed Nov 10 18:01:09 EST 2004
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
> 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
> 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))
Only it's a little weirder, because DEFCALLBACK is introducing
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.)
More information about the Openmcl-devel