Am Montag, dem 05.01.2026 um 15:35 +0100 schrieb Martin Uecker:
> Am Montag, dem 05.01.2026 um 15:21 +0100 schrieb Alejandro Colomar:
> > Hi Martin,
> >
> > On Mon, Jan 05, 2026 at 03:15:27PM +0100, Martin Uecker wrote:
> > [...]
> > > > This indeed matches the default behavior of both GCC and Clang, and
> > > > I expect to also match every other quality compiler.
> > > >
> > > > alx@devuan:~/tmp$ cat attr.c
> > > > [[attr]]
> > > > int
> > > > main(void)
> > > > {
> > > > return 0;
> > > > }
> > > > alx@devuan:~/tmp$ gcc attr.c
> > > > attr.c:1:1: warning: ‘attr’ attribute ignored [-Wattributes]
> > > > 1 | [[attr]]
> > > > | ^
> > > > alx@devuan:~/tmp$ clang attr.c
> > > > attr.c:1:3: warning: unknown attribute 'attr' ignored
> > > > [-Wunknown-attributes]
> > > > 1 | [[attr]]
> > > > | ^~~~
> > > > 1 warning generated.
> > > >
> > > > And in compilers that don't want to implement any attributes, it should
> > > > be trivial to emit a diagnostic saying "Attributes are not supported".
> > > >
> > > > Is that okay to you?
> > >
> > > I will keep arguing (and vote) against this. The reason is that
> > > attributes are
> > > syntactically designed and are useful as a language feature that is
> > > forwards-compatible, i.e. programmers can add annotations that can simply
> > > ignored by older C23 compiler (when looking from the future) without
> > > having
> > > to use macro wrappers. I think this is extremely useful in a long-term
> > > perspective, especially with regard to future annotations for safety.
> > > We also have no other feature like this, and if we invent yet another
> > > feature the oldest compiler to support it would be a future C2Y compiler
> > > and not a C23 compiler. So let's please not break attributes for this
> > > important use case before we even have started to use them properly.
> >
> > But both GCC and Clang (and every quality compiler, actually; show me
> > one that doesn't) ignore the C standard in this regard, because the
> > C standard has an Earthly Demon. You're ignoring reality.
> >
> > And after all, you're free to explicitly turn off this diagnostic, but
> > that's your choice. Constraint violations aren't hard errors.
>
> If you make it a constraint violation, a conforming implementation
> can reject a program with unknown attributes while now it is required
> to translate it. I would also perfer if Clang and GCC would not
> emit the warning by default, but a warning is still ok as long as the
> program is translated.
At the same time, there is nothing useful we would gain from your proposal.
If we want to introduce non-ignorable new language features, we can just
do this using a different syntax, just like we always do. There is absolutely
no reason to use attribute syntax for this. And if this feature is
non-ignorable, for example a new jump statement, then as I a reviewer and
reader of C code I also really want this to look very different from some
"hint" such as "nodiscard". I am also sure anybody working on any kind of
tooling that analysis C code appreciates that the tool can simply
ignore standard attributes if it wants to and keeps forward compatible to
any of such future hints we may want to add. You add a lot of unnecessary
cost to a lot people of you change this because then any such attribute
must be treated as potentially affecting semantics. So please don't.
Martin
