In message <87994A64-D80B-4C61-85B9-9D50D980B60E@mulle-
kybernetik.com>, Nat! wr
Can you show an example, where sending a superflous parameter to a C
function creates a problem with current Mach-O ABIs ?
No; I misinterpreted the question as being about safety and
general, rather than about specific API portability.
Does that mean it's actually safe to do this after all, under these
limited circumstances? I originally thought so, as I actually once
managed to call a function with too many parameters (it was a
horrible mess of typecasts -- don't ask, I was young and needed the
experience) and it didn't blow up in my face right away, which kinda
surprised me. But I just thought I'd been lucky.
I'm fully aware that there may be some other OSs and platforms and
ABIs where this wouldn't be valid, and it's definitely not ANSI C.
I'd merely need this for backwards compatibility with plugins and a
host app that will run on PowerPC and Intel so they're prepared for
handing us the additional parameter we need right now when we're
introducing the new Mach-O plugin scheme, even though the host app
isn't yet using the additional parameter (and can't require it
because legacy plugins don't yet know about the parameter.
Old plugin: callback();
New plugin: callback( contextPtr );
And we want new & old plugins to work on the host app now, while the
future host app will only accept new ones. It sounds like this will
work after all? Don't worry about portability, because even if a port
was planned, it'd require the new callback style *with* the context
pointer right away.
PS - Plum/Almisr/whatever your name is: Thanks for the ASCII ribbon.
It reminded me I'd have to check my reinstalled mail app whether it
generated HTML e-mail. It did :-( Sorry.
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: