<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 27, 2013, at 5:18 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 28.07.2013 um 01:08 schrieb John McCall:<br><blockquote type="cite">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?<br></blockquote><br>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.<br><br><blockquote type="cite">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*.<br></blockquote><br>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.<br></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite" dir="auto"><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;"><blockquote type="cite">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.<br></blockquote><br>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.<br></div></blockquote><div><br></div>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?</div><div><br></div><div>Also, if youíre going to compare the __OBJFW_RUNTIME__ value, you need to pick a version for -fobjc-runtime=objfw.</div><div><br></div><div><blockquote type="cite" dir="auto"> 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?</blockquote><br></div><div>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.</div><div><br></div><div>John.</div></body></html>