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. > 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. > But anybody who know how to look into the bug tracker of compilers, > should know that these attributes cause plenty of issues. Citation needed. 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 > > > > > > > > > > > > -- <https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
