Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!sdrc!thor!scjones From: scjones@thor.UUCP (Larry Jones) Newsgroups: comp.lang.c Subject: Re: Void function pointers Message-ID: <137@thor.UUCP> Date: 25 Jan 91 16:33:02 GMT References: <2887@casbah.acns.nwu.edu> <1991Jan24.181041.4894@Think.COM> Distribution: usa Organization: SDRC, Cincinnati Lines: 25 In article <1991Jan24.181041.4894@Think.COM>, barmar@think.com (Barry Margolin) writes: > In article sarroyo@govtdev-11w9.shearson.com (Suzanne Arroyo) writes: > [Regarding passing an int(*)() to a function expecting a void(*)()] > >this works, but is messy: > > foo ( 7, 3.131592653938789, (void(*)(int, double) )bar); > > Is this actually guaranteed to work right? What if the implementation uses > a different calling sequence for a function returning void from one > returning int? For instance, the space for a return value might be > allocated by the caller. Is this allowed (I know they are allowed to use > different calling sequences for varargs functions, but is the return type > also allowed to influence the calling sequence)? If so, then foo won't > call bar properly. No, it's not guaranteed to work right. It will work on many architectures for many return types, but not all. Structure return types are the most likely candidates for misbehavior because the space for a returned structure is frequently allocated by the caller and the address passed as an additional argument, so the call does not work. It is not possible to call a mis- declared function with predictable results -- casting to the correct type may shut up the compiler, but it won't make it right. ---- Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH 45150-2789 513-576-2070 Domain: scjones@thor.UUCP Path: uunet!sdrc!thor!scjones There's a connection here, I just know it. -- Calvin