On 14 June 2018 at 20:40, Jonathan Wakely <jwak...@redhat.com> wrote: >> Namely "For an attribute-token (including an attribute-scoped-token) >> not specified in this document, the behavior is >> implementation-defined.", aka [dcl.attr.grammar]/6. > > > As I said on IRC, if the user does > > #define gnu R"( > ,= ,-_-. =. > ((_/)o o(\_)) > `-'(. .)`-' > \_/ > )" > > then the attribute-scoped-token isn't even valid, and so the behaviour > of the implementation-defined gnu::nonnull attribute doesn't matter. > The code doesn't contain such an attribute. > > This seems like an unnecessary discussion: we should just use the > __attribute__ form instead.
That may well be, but deciding to handle preprocessor definitions of vendor attributes in a particular way doesn't make us non-conforming. The behaviour of a gnu::nonnull would, as far as I understand it, possibly include restrictions on what the preprocessor can do with it, just like the specification for standard attributes does. The preprocessor is part of the implementation, not a magical separate step that can do whatever it pleases. Conformance being a moot point, I'd prefer using the standard attribute syntax if we can, instead of using the gnuattribute syntax, but that's not a strong preference.
