site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Can you show an example, where sending a superflous parameter to a C function creates a problem with current Mach-O ABIs ? I.e.: Old plugin: callback(); New plugin: callback( contextPtr ); Host app now: callback() { ... } Host app future: callback( Context* contextPtr ) { ... } Cheers, -- M. Uli Kusterer http://www.zathras.de Am 24.08.2006 um 00:34 schrieb Peter Seebach: In message <87994A64-D80B-4C61-85B9-9D50D980B60E@mulle- kybernetik.com>, Nat! wr ites: No; I misinterpreted the question as being about safety and portability in 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. 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com