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. -- Jonathan _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
