Date: Fri, 27 Feb 2026 18:45:06 -0500
On Fri, Feb 27, 2026 at 1:03 PM Jan Schultke <janschultke_at_[hidden]> wrote:
>
>
>> > if (c >= 'a' && c <= 'z')
>>
>> This relies on ASCII being used, which I think should be mentioned. Somewhat
>> related, but C2Y is standardizing sequential hex digits so case'a'...'f' and
>> case'A'...'F' will work regardless of the character set used.
>
>
> Do you have a link for that?
>
>>
>> > case 0...9 is not valid because 0. and .9 are parsed as floating-point-literals, with one . between.
>>
>> 0...9 is parsed as one pp-number, rather than three tokens.
>
>
> Hmm, I was under the impression that the pp-tokens are broken up into one or more tokens, so that's what you would eventually get those three tokens out of it.
Preprocessing tokens are not broken up when converting to tokens. For example
0XE+2 is not broken up into 0XE, +, and 2. Similar issues can also occur with
user defined literals.
>
>
>> > if (c >= 'a' && c <= 'z')
>>
>> This relies on ASCII being used, which I think should be mentioned. Somewhat
>> related, but C2Y is standardizing sequential hex digits so case'a'...'f' and
>> case'A'...'F' will work regardless of the character set used.
>
>
> Do you have a link for that?
>
>>
>> > case 0...9 is not valid because 0. and .9 are parsed as floating-point-literals, with one . between.
>>
>> 0...9 is parsed as one pp-number, rather than three tokens.
>
>
> Hmm, I was under the impression that the pp-tokens are broken up into one or more tokens, so that's what you would eventually get those three tokens out of it.
Preprocessing tokens are not broken up when converting to tokens. For example
0XE+2 is not broken up into 0XE, +, and 2. Similar issues can also occur with
user defined literals.
Received on 2026-02-27 23:48:33
