<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Jul 26, 2013, at 5:05 PM, Jonathan Schleifer <<a href="mailto:js@webkeks.org">js@webkeks.org</a>> wrote:<br><div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Am 27.07.2013 um 01:54 schrieb John McCall:<br><blockquote type="cite">The feature enables users to rely on arbitrary message forwarding if they're willing to live on certain minimum compiler and runtime versions. That’s a pretty simple and comprehensible message for users.<br><br>In fact, if I remember correctly, we didn’t actually support generating code correctly for your runtime until fairly recently, so your users are all perfectly aware of the concept of a minimum compiler version.<br></blockquote><br>You are oversimplifying things here. There was no support for the ObjFW runtime before 3.2, but that didn't mean that Clang 3.1 could not work with it: It could, and it worked well, it was just that certain features were unavailable.<br><br>This, however, is different. It will mean that using an old Clang version or GCC will generate *crashing code* instead of a feature being unavailable. That's a completely different thing!<br></div></blockquote><div><br></div>It’s going to generate crashing code anyway. You can’t statically detect that the user’s using this feature — you’d, what, add code to the compiler that detects that the user has defined forwardingTargetForSelector: in a way that might accept a selector that you think probably has an indirect return? So in practice the process from the user’s perspective is:</div><div><br></div><div>1. The user writes some code that relies on proxying.</div><div>2. It compiles without complaint.</div><div>3. It crashes because they’re using an old compiler or runtime (but not immediately — only when the first indirect-return message is forwarded).</div><div>4. The crash is exactly the same regardless of the runtime version, because the old compiler is calling objc_msg_lookup, and as long as proxying is enabled *at all* for this target, objc_msg_lookup will return back the non-indirect forwarding function and the current behavior will recur.</div><div>5. The user figures out, somehow, that it’s because of this bug with proxying methods with indirect returns.</div><div>6. The user finds your documentation about this, which says that they need a new compiler version.</div><div>7. Profit?</div><div><br></div><div>The only way that this preprocessing check is useful at all is if the user’s reaction to this is “Oh, I can't upgrade my compiler; I’ll just add workarounds every time I run into this crash, but I want to disable them when the runtime feature is enabled.” And that might be a rational reaction, but it’s a rational reaction to *any possible compiler bug*.</div><div><br></div><div>I think that exposing the value of -fobjc-runtime as preprocessor state is a pretty reasonable request, although I don’t see how it solves this problem at all.</div><div><br></div><div>John.</div></body></html>