On Mon, Jul 8, 2013 at 12:00 PM, Jonathan Schleifer <[email protected]> wrote: > Am 08.07.2013 um 19:22 schrieb Eli Friedman: > >> If you are going to call a function for nil receivers, you have to have a >> specialized fpret form for x86-32: otherwise, the program will misbehave due >> to mismatched push/pop on the FP stack. > > Yes, but this won't be a problem for forwarding, I guess. And for handling > nil correctly, it sounds like letting the compiler do the magic is a much > more robust way, even though it might bloat the code a little. But it has the > advantage of even working on platforms where the dispatch is not done in > assembly, but in pure C. > > It would be possible to have a method return_fpnil or something that just > returns nil and could be returned by objc_msg_lookup_fpret, though. But then > again, it's highly platform-dependant what type(s) exactly need(s) fpret. > >> That said, it wouldn't be unreasonable to just nil-check before any call >> that doesn't have an integer/pointer return; on the Mac side, we actually do >> such a check anyway for structs because we zero-initialize them. > > Great, so there is already code for that :). > > Do you agree that if not taking nil-messaging into account and letting the > compiler handle that there is no need for objc_msg_lookup_fpret? I could not > think of a reason why it would be required for forwarding.
If you ignore nil-messaging, you don't need any of these specialized versions: objc_msg_lookup can always return a pointer to a function of an appropriate type without any special knowledge of what that type is. -Eli _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
