r187174 - Fix GNU ObjC ABI for a message returning a struct.

John McCall rjmccall at apple.com
Mon Jul 29 10:39:51 PDT 2013

On Jul 27, 2013, at 5:18 PM, Jonathan Schleifer <js at webkeks.org> wrote:
> Am 28.07.2013 um 01:08 schrieb John McCall:
>> 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?
> Of course the compiler can't verify it, but that's not the point. The point is that there is a way to check if forwarding structs would work. If not, you can disable a feature that requires forwarding. E.g. an application might only enable its remote support if it can be sure that forwarding structs would not crash.
>> 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*.
> That's almost the idea. The idea is that the developer can check at compile time if struct forwarding works or not and if not #error out. That's still better than code being deployed and suddenly crashing! It can advise the user to update the compiler. Or if only an optional feature depends on it just disable that optional feature.

Okay, so this is the use case of a source-distributed library where the code author can’t actually just control the compiler?  Fair enough.  But yes, I think if you want to advertise this, you need to do it from your headers.

>> 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.
> I added an __OBJFW_RUNTIME__ define similar to __NEXT_RUNTIME__ that defines the version as 0xMMNN, where MM is the major and NN the minor of the version.

This seems reasonable, but our supported version scheme is actually X.Y.Z.  You’re sure you’ll never want to use sub-minor releases?

Also, if you’re going to compare the __OBJFW_RUNTIME__ value, you need to pick a version for -fobjc-runtime=objfw.

>  What I did notice is that -fobjc-runtime=objfw-100000 can theoretically be specified by the user (which would of course set the define to nonsense). However, this is not the real problem, IMHO: Clang should error out if the specified version is higher than the maximum supported version. Is this not done intentionally or is the code for that just not written yet?

We’re not going to hardcode the ObjFW release history into the compiler. :)  You’d potentially have to patch us (and require a new compiler) every time you issued a new release, which is why we don’t sanity-check version numbers for anything else.  If you want to have this check in your headers (“targeting a new runtime version, but not using up-to-date headers?”), go ahead.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130729/811247cf/attachment.html>

More information about the cfe-commits mailing list