<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jun 14, 2015 at 11:40 AM, Jonathan Schleifer <span dir="ltr"><<a href="mailto:js@webkeks.org" target="_blank">js@webkeks.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Am 14.06.2015 um 19:50 schrieb Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>>:<br>
<br>
> The use of this feature is too widespread in iOS/OS X to change the spelling there. The feature was in the Xcode 6.3 release notes, the subject of a Swift blog entry, and has been adopted in the wild. It is too late.<br>
<br>
</span>Which is why I suggested to have __nonnull as an alias to whatever the new name would be on OS X / iOS. Can you please elaborate why that would not be a solution? All existing code will keep working.<br>
<span class=""><br>
> You're jumping to the conclusion that this is an unresolvable conflict and that it's the language feature that must change. We might have overlapping features, or an easy way to teach Clang to account for the differences. Creating a terminology schism has costs, too, if both uses are driving toward the same goal.<br>
<br>
</span>I don't see where this is a problem of overlapping features. It's an issue of using a name that is already used.<br>
<span class=""><br>
> What breaks due to this conflict?<br>
<br>
</span>Well, there are two cases we have to look at: The case where Clang supports nullability and the case where it doesn't.<br>
<br>
Let's start with the one that has nullability:<br>
glibc defines __nonnull in sys/cdef.h. This will change the behavior of __nonnull to that that glibc wants. If you now want to use code that uses the __nonnull from Clang, things will not compile.<br></blockquote><div><br></div><div>__nonnull is defined as a function-like macro, so any use that is not followed by a ( will work fine. That makes the portability problem significantly less severe.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now for the case where you don't have nullability:<br>
You add __nonnull to your code to have the new nullability feature on OS X / iOS. Because this is not available in upstream Clang yet, you add code like:<br>
<br>
#if !__has_feature(nullability)<br>
# define __nonnull<br>
# define __nullable<br>
#endif<br>
<br>
Now, __nonnull is already defined and thus this won't work. You might think that it's a good idea to just #undef __nonnull. However, this will break the glibc headers.</blockquote><div><br></div><div>That seems like an odd way to deal with that portability problem. The conventional way is:</div><div><br></div><div>#if __has_feature(nullability)</div><div>#define NONNULL __nonnull</div><div>#else</div><div>#define NONNULL</div><div>#endif</div><div><br></div><div>... which again works without problems so long as you don't follow NONNULL with a left parenthesis.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Your tone here is not conducive to a productive discussion. We don't vilify vendors nor patronize it's developers here in the Clang community. Keep it civil and keep it technical.<br>
<br>
</span>I don't see how my tone here is not productive - I was merely suggesting what to do to prevent this in the future, as this is not the first time of this is happening and I'm sensing a pattern here. These were suggestions to make sure this won't happen again. The whole __block thing was a real problem for quite a long while.<br>
<span class=""><br>
> And, for the record, this language feature has been tested on Linux and this did not manifest as an observable problem there.<br>
<br>
</span>Could you share what exactly you tested? For me, even the case where your Clang doesn't support nullability fails, so I didn't even bother trying further after that, as that was already a complete blocker to using __nonnull.<br>
<span class=""><br>
> You missed my point completely.<br>
><br>
> Conflicts over syntax happen, even under the most idealized situation of well-established languages and slow-moving standards committees. We don't point fingers, we dive into the technical problem and come up with a solution. And most of the time, it's worked out quite well in Clang.<br>
><br>
> A quick search shows that glibc is defining __nonnull as a function-like macro, so this conflict is trivial to resolve.  Is there something more I've missed that causes an actual problem?<br>
<br>
</span>How is this trivially fixed other than changing it in glibc to have a different name? Could you please elaborate? The only other way I can think of is not making __nonnull available for system headers, which, honestly, strikes me as a bad idea as that means system headers can't define libc functions a __nonnull, which might be quite useful.<br>
<br>
--<br>
Jonathan<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>