[cfe-dev] RFC: Nullability qualifiers

[Richard Smith]

On Sun, Jun 14, 2015 at 12:59 PM, Jonathan Schleifer <js at webkeks.org> wrote:

> Am 14.06.2015 um 21:39 schrieb Richard Smith <richard at metafoo.co.uk>:
>
> > __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.
>
> Hm, indeed, weird. I got some errors about not giving it enough arguments,
> however, I can't reproduce what I did there.
>
> > 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.
>
> I disagree about this being odd. As a counter example, restrict was added
> in C99. #define restrict was a very common thing to make sure it still
> compiles as C89.
>

Well, 'restrict' was not a reserved identifier in C89. __nonnull is a
reserved identifier in all C-family languages. But you're right, some
people might be #defining __nonnull themselves, and if they do, their code
will be non-portable.


> As for using a hack with a define, this is what I did for now. Still, it's
> a hack and makes all declarations look ugly and weird. Wouldn't it be much
> nicer to have a keyword that you can just define to nothing for backwards
> compatibility, like with restrict? (That does not mean we can't keep
> __nonnull in addition to another name on OS X / iOS, so it would not break
> any existing code).
>

I don't think that using two separate reserved identifiers for this keyword
is really much nicer than using one. If we could use a 'prettier' keyword
for this, like "nonnull", that might be nicer, but we really don't want
Clang to introduce its own non-conforming language mode like that. But you
can create this state of affairs yourself with a #define.


> I wonder if it makes sense to bring up this issue with the glibc
> maintainers as well?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150615/d2338cd0/attachment.html>