On Tue, Mar 15, 2022 at 9:48 PM Bret Brown via SG15
<sg15_at_[hidden]> wrote:
>
> Hi all!
>
> It's interesting that all the tools I've looked at have a hard time distinguishing between misspellings of attributes and user-defined attributes.
>
> Given that, and the need to keep the SG15 backlog populated, I have marked a paper on the subject for review, though I believe I just missed the filing deadline. It might be officially published in the April mailing.
>
> Here is the paper: https://isocpp.org/files/papers/P2565R0.pdf
>
> Here is the abstract:
>
> While the standard supports vendor-provided and otherwise user-defined attributes in C++, actual use of nonstandard attributes while preventing trivial misspellings is a challenge. In particular, diagnostics in compilers used to prevent misspellings of standard and well-known attributes will reject attributes provided for other contexts, including attributes used to support other compilers. This document explores how this problem presents itself in practice and proposes a potential attribute declaration syntax to address the problem.

Thanks for this paper! Once you've gotten farther along with the
design aspects of it and think it's ready for a wider audience, I
think the proposal will need to be seen by SG22 as C now shares the
same attribute syntax and attributes show up *very* frequently in
header files (which may be shared between languages).

On the paper itself:

I appreciate that the choice of syntax could be compatible with C
right out of the gate.

As an implementer, I sympathize with the problem you're trying to
solve. But one of the primary reasons why Clang diagnoses *all*
unknown attributes by default is two-fold: typos (as the paper
mentions) and programmer intent (the paper doesn't clearly discuss
this case, but it comes close). When the programmer writes an
attribute in the source code, they intend for that attribute to have
*some* effect. It could be that the effects are hints that are safe to
ignore in some form (like many of the standard attributes), but for
vendor-specific attributes all bets are off on how safe it is for the
implementation to not support the attribute. My users generally want
these diagnostics, especially because attributes can have security
impacts. As a concrete example, ignoring a deprecated attribute is
annoying but likely harmless for the user's build; ignoring a calling
convention attribute on a library interface called from another
executable is quite likely harmful unless the stars line up right for
you.

Giving the user the control to say "please ignore this attribute if
it's unknown" has some appeal and I may be in support of this feature,
but I'm also worried that this is overstepping into the QoI realm,
especially given that vendor-specified attributes are wholly
implementation-defined. I'd be helpful for the paper to go into more
detail on why the common implementation practices users use are
inappropriate. FWIW, my experience has been that the few users who
have brought up concerns about unknown attribute diagnostics generally
grumble about needing to write the macros when it's pointed out that's
how this is typically handled, but once they introduce the first such
macro to their code, I've not heard further complaints from them about
it. It's also worth pointing out that those macros won't be going away
any time soon even if we adopt this proposal -- there's a fair number
of code bases that need to support older compilers/language modes. I
would say that the status quo is largely acceptable to my users
already.

"The implication of widespread preprocessor wrapping logic is that
vendor-defined attributes are not working as originally intended."

I disagree with this; vendor-specified attributes were never intended
to be portable in the first place, only the *syntax* was portable so
that all the vendors can lexically munch the correct amount of tokens
to be able to handle them in a general way.

~Aaron

>
>
> Regards,
> Bret Brown
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15