site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=aL83bo/75k4oIqBTNtom5rAm0Edb0ZrAq9Sqizd1GCPtH0x82PRh3fcQNpexTN+0N3pC4DEO/YIkjfCb48nWU1VU4u7L+jFjI8Fhh5h/hEu6A+891jnFq1uaxecWkDJ5pq8b+TqZESHub4qxVy/xyJHQzsJWfwkYO1VrJzQhDMU= On 20/ago/06, at 12:17, Uli Kusterer wrote: Hi, int main() or int main( int argc, const char* argv* ) Camillo _______________________________________________ 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... you know how main() can be declared with varying parameter counts, like and even more. Does this work for any function? If I pass a function more parameters than it actually uses, is that safe with OS X's current Mach-O ABIs? I would like to have plugins in my app be prepared for a future expansion of the plugin protocol, which would require them to pass an additional parameter (that my app isn't using right now) to the callbacks they send. Since I'm gonna be releasing a new plugin SDK with the first universal version, I thought this would be a good opportunity to add this change, so that all recompiled Xes would run unchanged on the future new system and I can drop the old code that doesn't have this parameter. I trid googling for "Mach O ABI too many parameters" and stuff like that, but I just couldn't find any clues there, so if anyone knows where I can find this documented or even has an answer, that would be cool! I just read this thread, and although it's old, it seems that it did not reach a conclusion, so forgive me for resurrecting it. :) If you look at the PPC and IA32 ABIs, it seems that what you want to do is safe. Here is the PPC32 ABI: <http://developer.apple.com/documentation/DeveloperTools/Conceptual/ LowLevelABI/Articles/32bitPowerPC.html> Note that space for the parameters is allocated in the caller's stack frame (most parameters are passed in registers, but space is still allocated for them on the stack). On entry, the called function sees a 24-byte linkage area at SP, and the parameter area at SP+24. The parameter area is large enough to hold parameters for all functions the caller wants to call; the callee does not need to know its exact size, since arguments are allocated in left-to-right order at increasing addresses starting at SP+24: the callee just looks at the lowest chunk of the parameter area, corresponding to the leftmost arguments (however many it expects), and ignores the rest. The same goes for the arguments passed in registers: the callee will use the ones it needs, and ignore/clobber the rest. Here is the IA32 ABI: <http://developer.apple.com/documentation/ DeveloperTools/Conceptual/LowLevelABI/Articles/IA32.html> The parameter area is allocated and deallocated by the caller, and arguments are allocated in order starting at SP and growing upwards. The situation is the same as on PPC. Therefore, I'd say you're safe to add parameters as you wish. Of course, the later versions of the callee must be prepared to receive garbage in the extra arguments from older callers. This email sent to site_archiver@lists.apple.com