[cfe-dev] RFC: Nullability qualifiers

[Richard Smith]

On Sun, Jun 14, 2015 at 11:40 AM, Jonathan Schleifer <js at webkeks.org> wrote:

> Am 14.06.2015 um 19:50 schrieb Douglas Gregor <dgregor at apple.com>:
>
> > 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.
>
> 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.
>
> > 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.
>
> I don't see where this is a problem of overlapping features. It's an issue
> of using a name that is already used.
>
> > What breaks due to this conflict?
>
> Well, there are two cases we have to look at: The case where Clang
> supports nullability and the case where it doesn't.
>
> Let's start with the one that has nullability:
> 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.
>

__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.


> Now for the case where you don't have nullability:
> 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:
>
> #if !__has_feature(nullability)
> # define __nonnull
> # define __nullable
> #endif
>
> 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.


That seems like an odd way to deal with that portability problem. The
conventional way is:

#if __has_feature(nullability)
#define NONNULL __nonnull
#else
#define NONNULL
#endif

... which again works without problems so long as you don't follow NONNULL
with a left parenthesis.

> 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.
>
> 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.
>
> > And, for the record, this language feature has been tested on Linux and
> this did not manifest as an observable problem there.
>
> 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.
>
> > You missed my point completely.
> >
> > 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.
> >
> > 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?
>
> 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.
>
> --
> Jonathan
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150614/90aca9de/attachment.html>