On Jul 26, 2013, at 5:05 PM, Jonathan Schleifer <[email protected]> wrote:
> Am 27.07.2013 um 01:54 schrieb John McCall:
>> 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.
>>
>> 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.
>
> 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.
>
> 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!
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:
1. The user writes some code that relies on proxying.
2. It compiles without complaint.
3. It crashes because they’re using an old compiler or runtime (but not
immediately — only when the first indirect-return message is forwarded).
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.
5. The user figures out, somehow, that it’s because of this bug with proxying
methods with indirect returns.
6. The user finds your documentation about this, which says that they need a
new compiler version.
7. Profit?
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*.
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.
John.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
