On 14/06/18 20:27 +0300, Ville Voutilainen wrote:
On 14 June 2018 at 20:21, Ville Voutilainen <ville.voutilai...@gmail.com> wrote:
On 14 June 2018 at 20:08, Jonathan Wakely <jwak...@redhat.com> wrote:
Oops, indeed. But for gnu-attributes, surely we can decide whatever we
want about what's
valid and what's not?
We could say that #defining 'nonnull' and/or 'gnu' as a macro is
undefined, but then programs that the standard says are valid would
fail to compile, and we'd be a non-conforming implementation.
We can use __attribute__(__nonnull__)) so that we accept those
programs (and be a conforming implementation). Why would we choose to
be non-conforming when we don't have to?
I can read the specification liberally enough that it might give us
the freedom to disallow programs
that #define names that our implementation uses for vendor attributes.
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.
