Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Thu, 3 Apr 2025 13:21:18 -0500
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <vsmjln$19uet$1@dont-email.me>
References: <87y0wjaysg.fsf@gmail.com> <vsj1m8$1f8h2$1@dont-email.me>
 <vsj2l9$1j0as$1@dont-email.me> <vsjef3$1u4nk$1@dont-email.me>
 <vsjg6t$20pdb$1@dont-email.me> <vsjgjn$1v1n4$1@dont-email.me>
 <vsjk4k$24q5m$1@dont-email.me> <vsjlcp$230a5$1@dont-email.me>
 <vsjmdl$277bk$1@dont-email.me> <VsdHP.1828827$TBhc.1078002@fx16.iad>
 <vskaas$2rit9$1@dont-email.me> <vslehd$28l7$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 03 Apr 2025 20:22:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a7d2e5b2e6e147929ab1679437fac851";
	logging-data="1374685"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18mMdF2ToK3WIDchmLEem4YvouddERfysE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MzTq0nsGVL2c14sJYFxt5J+92gY=
In-Reply-To: <vslehd$28l7$3@dont-email.me>
Content-Language: en-US
Bytes: 5159

On 4/3/2025 2:49 AM, David Brown wrote:
> On 02/04/2025 23:31, Janis Papanagnou wrote:
>> On 02.04.2025 18:20, Scott Lurndal wrote:
>>> Muttley@dastardlyhq.com writes:
>>>> On Wed, 2 Apr 2025 16:33:46 +0100
>>>> bart <bc@freeuk.com> gabbled:
>>>>> On 02/04/2025 16:12, Muttley@DastardlyHQ.org wrote:
>>>>>> Meh.
>>>>>
>>>>> What's the problem with it? Here, tell me at a glance the magnitude of
>>>>> this number:
>>>>>
>>>>>      10000000000
>>>>
>>>> And how often do you hard code values that large into a program? Almost
>>>> never I imagine unless its some hex value to set flags in a word.
>>
>> I can't tell generally; it certainly depends on the application
>> contexts.
>>
>> And of course for bases lower than 10 the numeric literals grow
>> in length, so its usefulness is probably most obvious in binary
>> literals. But why restrict a readability feature to binary only?
>>
>> It's useful and it doesn't hurt (WRT compatibility).
>>
>>>
>>> Every day, several times a day. 16 hex digit constants are very
>>> common in my work.  The digit separator really helps with readability,
>>> although I would have preferred '_' over "'".
>>
>> Obviously a question of opinion depending on where one comes from.
>>
>> I see a couple options for the group separator. Spaces (as used in
>> Algol 68) are probably most readable, but maybe a no-go in "C".
>> Locale specific separators (dot and comma vs. comma and dot, in
>> fractional numbers) and the problem of commas infer own semantics.
>> The single quote is actually what I found well suited in the past;
>> it stems (I think) from the convention used in Switzerland. The
>> underscore you mention didn't occur to me as option, but it's not
>> bad as well.
>>
> 
> Once you have eliminated punctuation that would already have a different 
> meaning in the syntax of the language, you very quickly get down to 
> three choices, AFAICS - underscore, single quote or double quote.  When 
> C++ added digit separators, they had already used underscore for user- 
> defined literals, so that was ruled out.  I don't know if double 
> quotation marks could have been used, or they were ruled out for other 
> reasons, but C++ settled on single quotation marks.  Then C followed 
> suit, because re-inventing an incompatible wheel would have been insane.
> 
> With hindsight, it might have been nicer to use underscore for digit 
> separators and single quote marks for user-defined literals in C++ (in 
> the manner of attributes in Ada), but the fact that underscore is 
> effectively a letter in C and C++ was very relevant for its choice in 
> user-defined literals.
> 

Could have made sense to make a distinguishing rule that whether or not 
_ is understood as a digit or user-defined literal depends on whether 
the following character is also a valid digit.

So, 0x0000_0000 is a digit separator, because it is followed by a digit.


Can note that, in my case, whether 'z' or 'x' are allowed in a literal 
depends on both the base (only allowed for now in hex and binary 
literals, but not octal or decimal) and the suffix (they are only valid 
if the number token would end with a width-specifying number suffix, *1).

But, one could argue that this does make tokenizing more annoying, as 
whether to end or continue the token depends on characters following the 
character in question (so, there is a need to add some complexity to 
"what if?" it slightly...).

This was in turn because Verilog literal syntax, say, 16'h9zz1, wasn't 
really a fit for C either...

*1: Say, iNN, uiNN, or uNN, where NN being the number of bits.
   0x12345678i32  //exact-width, 32-bit signed literal.
   0x12345678u32  //exact-width, 32-bit unsigned literal.

....


> 
>