Am Montag, dem 05.01.2026 um 19:00 +0100 schrieb Alejandro Colomar:
> Hi Martin,
>
> On Mon, Jan 05, 2026 at 06:47:33PM +0100, Martin Uecker wrote:
> > 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.
>
> The undefined behavior isn't in that structure definition, but using it
> will certainly result in UB, because it's breaking ABI.
>
> >
> > 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.
>
> s/may/definitely will/
>
> That's an ABI break.
This is not clear. For other attributes it could be different,
but even for "packed" it may not be the case, because it is not used across
some interface boundary and ignoring it just causes some loss of performance
because the struct does not fit into a cachline or something.
But I agree that vendor-attributes can be a safety risk, and
a warning it ok in this case. But we already get this warning.
>
> > 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.
>
> Okay, let's use scoped attributes. Those are non-ignorable and harmful.
> The benefit of attributes is having a standard placement and syntax.
> Adding dozens of keywords is not proper language design.
We hopefully do not add dozens of new features anyway. Attributes
certainly have the advantage that they are not reserved identifiers
(although they still can collide with macro names), but I do not see
this as a major issue. (library functions are a much bigger problem).
The standard / syntax of attributes is a limitation to make them
ignorable. For new features we do not have this limitation, but
we can certainly make it fit in with the rest of the language.
I am also ok with having a common syntactic space for minor or
experimental language features, maybe also inside the attribute
space as you suggest, but we also need a clearly separated space
for ignorable annotations with forward compability and those
should be clearly distinguishable.
>
> > But anybody who know how to look into the bug tracker of compilers,
> > should know that these attributes cause plenty of issues.
>
> Citation needed.
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&f1=component&f2=short_desc&list_id=501114&o1=equals&o2=substring&order=Importance&query_format=advanced&v1=c&v2=attribute
Not all of those are real issues, this includes documentation issues,
enhancement requests, etc. But there plenty of issues where the
semantics of attributes is unclear or their interaction with other
language features is unclear or broken.
Don't get me wrong, I think vendor attributes are a very good tool
for a vendor to experiment with new features without intruding into
the main syntactic space of the language, but once we decide to
standardize a feature, we should look at all the issue that came
up and try to come up with a design that takes the practical
experience into account. But at that point we can also give it
some real syntax in my opinion.
Martin
>
>
> Cheers,
> Alex
>
> >
> > 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
> > > >
> > > >
> > > >
> > > >
