Am Montag, dem 05.01.2026 um 18:25 +0100 schrieb Alejandro Colomar:
> Hi Martin,
>
> On Mon, Jan 05, 2026 at 03:42:54PM +0100, Martin Uecker wrote:
> > > 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.
>
> And remember, an implementation is also required to implement
>
> struct [[alx::packed]] foo {
> char a;
> int64_t b;
> char c;
> int64_t d;
> };
>
> exactly as
>
> struct foo {
> char a;
> int64_t b;
> char c;
> int64_t d;
> };
>
> (because no implementation recognizes alx:: attributes.)
>
> If this is not an Earthly Demon, tell me what is.
I don't know but as the behavior is specified to ignore the attribute
when it is not supported, it is not undefined behavior, so not an
Earthly Demon.
If the attribute were supported, it is implementation-defined behavior
that does not need to be ignorable. This is more of an issue, because
ignoring this implementation may break your program. So I agree that for
non-standard attribute a warning makes sense.
But there are many use cases also for non-standard attributes, e.g.
annotations for a third-party tool. Why should those be a constraint
violation?
And for a future standard attribute which is ignorable, there is no
issue. Ignoring it just fine! So adding it also safe and cheap:
One does not have to worry that the code breaks on older compilers
or other tools, and when it is processed by older compilers or tools
it still works fine. This is extremely useful!
>
> > > 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.
>
> As a starter, we'd reject the code shown above. That's a useful gain,
> isn't it?
I can already get a warning. Nobody needs to do anything.
>
> But okay, I give up on trying to fix non-scoped attributes.
>
> Since Aaron complained about stdc::attr attributes because they wouldn't
> be useful in C++, my third attempt at having useful attributes will be
> [[::attr]]. This should be acceptable in C++, because there's no
> prefix, and thus nothing that says anything about C. Does this sound
> good to you?
I think we should design proper language features instead. If you
have something such as "packed" you need to think how the affects
your type system etc. Then why use attribute syntax for this? This
just misleads people into thinking it is something easy and harmless.
But anybody who know how to look into the bug tracker of compilers,
should know that these attributes cause plenty of issues.
Martin
>
>
> Have a lovely night!
> Alex
>
> > 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
> >
> >
> >
> >
