On Wed, 9 Jul 2025 at 13:03, Corentin <corentin.jabot_at_[hidden]> wrote:

> On Wed, Jul 9, 2025 at 9:49 PM Richard Smith <richardsmith_at_[hidden]>
> wrote:
>
>> On Wed, 9 Jul 2025 at 11:49, Jens Gustedt via Core <core_at_[hidden]>
>> wrote:
>>
>>> Hi,
>>>
>>> Am 9. Juli 2025 20:15:57 MESZ schrieb Corentin via Liaison <
>>> liaison_at_[hidden]>:
>>> > On Mon, Jul 7, 2025 at 7:38 PM Jens Maurer <jens.maurer_at_[hidden]>
>>> wrote:
>>> >
>>> > >
>>> > >
>>> > > On 07.07.25 17:41, Corentin via Core wrote:
>>> > > > Hey folks,
>>> > > >
>>> > > > [[foo(#)]] is a valid attribute in C, but invalid in C++, as # is
>>> > > considered a token in C and a preprocessing-operator in C++
>>> > > > (The grammar of attributes expects tokens in both languages)
>>> > > >
>>> > > > Is this divergence intended? It does not seem desirable.
>>> > > >
>>> > > > Note that there is implementation divergence amongst C++ compilers
>>> here,
>>> > > Clang accepts in all language modes, GCC rejects in all language
>>> modes
>>> > > https://godbolt.org/z/Wj5fqdd1x <https://godbolt.org/z/Wj5fqdd1x>
>>> > >
>>> > > Looks like ## should have the same divergence.
>>> > >
>>> >
>>> > yes, the same question applies to all of #, ##, %:, %:%:
>>>
>>> Actually to all preprocessor tokens, that have no equivalent
>>> in translation phase 7. these are probably a lot more than the ones
>>> listed.
>>>
>>
>> In addition to # and ##, in the basic source character set there's also
>> ` @ $ \ which satisfy the "single character that's not the start of another
>> preprocessing-token" rule. EDG rejects all of those, GCC and MSVC
>> reject all but $, clang accepts all.
>>
>> Then there are pp-numbers that don't correspond to tokens, such as
>> 0xhello. GCC and Clang accept that in an attribute, EDG and MSVC reject.
>>
>
> Interestingly, GCC also tries to form UDLs https://godbolt.org/z/r6K3Thd1d
>
>

I think that also gives a pretty strong justification for allowing
arbitrary pp-numbers as attribute arguments: these come up for version
numbers. And indeed Clang has an attribute, in use in production, that
accepts a pp-number that's not a token. For example:

[[clang::availability(linux, introduced=2.6.16)]]
int faccessat(int dirfd, const char *pathname, int mode, int flags);

This attribute is accepted by Clang and successfully ignored by MSVC, but
GCC and EDG fail to ignore it and instead diagnose the pp-number having too
many decimal points.

Should we add a new kind of token for "miscellaneous preprocessing-token
that is not otherwise a token", that's only valid within attributes?


> (Summary: EDG rejects all pp tokens that aren't tokens. Clang accepts all
>> of them. GCC and MSVC are inconsistent but mostly reject.)
>>
>> It seems like it might be useful to accept pp-numbers that don't match
>> numeric literal syntax. But the rest seem a little questionable: I don't
>> think we should accept a stray \ -- even in a macro argument, that seems
>> like it should be reserved for metasyntactic uses, and notably you wouldn't
>> be able to wrap a line after it -- and at least MSVC produces a good
>> diagnostic for a stray # or ## that would presumably suffer if we accepted
>> those as attribute arguments. (But maybe someone has use for an attribute
>> that contains a macro definition?)
>>
>> Do we want to reserve tokens starting with ` @ or \ for future extension?
>> If so, that might be a reason to not allow them as macro arguments.
>>
>> Jens G
>>> >
>>> >
>>> > >
>>> > > Jens
>>> > >
>>> > >
>>> > > > https://eel.is/c++draft/lex.operators#1 <
>>> > > https://eel.is/c++draft/lex.operators#1>
>>> > > > https://eel.is/c++draft/lex.token#nt:token <
>>> > > https://eel.is/c++draft/lex.token#nt:token>
>>> > > > https://eel.is/c++draft/dcl.attr#nt:balanced-token <
>>> > > https://eel.is/c++draft/dcl.attr#nt:balanced-token>
>>> > > >
>>> > > > _______________________________________________
>>> > > > Core mailing list
>>> > > > Core_at_[hidden]
>>> > > > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
>>> > > > Link to this post: http://lists.isocpp.org/core/2025/07/18326.php
>>> > >
>>> > >
>>>
>>>
>>> --
>>> Jens Gustedt - INRIA & ICube, Strasbourg, France
>>> _______________________________________________
>>> Core mailing list
>>> Core_at_[hidden]
>>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
>>> Link to this post: http://lists.isocpp.org/core/2025/07/18337.php
>>>
>>