Re: Which flavor of objc_msgSend for NSSize return
Re: Which flavor of objc_msgSend for NSSize return
- Subject: Re: Which flavor of objc_msgSend for NSSize return
- From: Greg Parker <email@hidden>
- Date: Fri, 11 May 2007 22:04:57 -0700
On May 11, 2007, at 9:26 PM, Sherm Pendley wrote:
On May 11, 2007, at 11:40 PM, Greg Parker wrote:
Sherm Pendley wrote:
When I call objc_msgSend_stret() in CamelBones, I call it as
documented in the runtime reference, returning the struct by
reference in the first argument. It's much simpler, with no need
for the typecast.
Never call any objc_msgSend function without casting to an
appropriate function pointer type.
In CamelBones, I'm talking about a language bridge function that
takes parameters from Perl's call stack and uses ffcall to build the
call stack for objc_msgSend*(). It's not a simple static function
call with the argument and return types known at compile time. While
your advice is undoubtedly sound for most situations, a compile-time
cast isn't an option when the argument and return types aren't known
until run time.
In fact, ffcall itself isn't very flexible with respect to structure
types that are unknown at compile time.
In that case, you should describe your call as "returns struct" rather
than "returns void with struct address as first parameter", and hope
that ffcall does the right thing for choosing the calling convention.
ffcall's documentation suggests that it makes the right memory vs.
registers decision for i386 structures. But if flexibility is a
problem, you might be able to get away with describing all large
structures the same way, as ffcall might not need to know exactly how
big it is once it's decided it must be returned in memory.
The other issues with uncast objc_msgSend shouldn't come up. They all
deal with value promotion and ABI differences when calling `...`
prototypes. You should be safe there as long as the types you provide
for the parameters match the types expected by the methods.
I chose it many moons ago, because at the time Fink and DarwinPorts
didn't yet exist; the only way to obtain libffi was to build my own
copy of GCC - not an attractive prospect. I think I'll have to
revisit that decision now...
libffi is the recommended solution now. The ruby-objc and python-objc
bridges both use it.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden