Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Hex string literals (was Re: C23 thoughts and opinions)
Date: Wed, 19 Jun 2024 09:37:20 +0200
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <v4u1rg$1rslf$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me>
 <87msoh5uh6.fsf@nosuchdomain.example.com>
 <f08d2c9f-5c2e-495d-b0bd-3f71bd301432@gmail.com>
 <v2nbp4$1o9h6$1@dont-email.me> <v2ng4n$1p3o2$1@dont-email.me>
 <87y18047jk.fsf@nosuchdomain.example.com>
 <87msoe1xxo.fsf@nosuchdomain.example.com> <v2sh19$2rle2$2@dont-email.me>
 <87ikz11osy.fsf@nosuchdomain.example.com> <v2v59g$3cr0f$1@dont-email.me>
 <87plt8yxgn.fsf@nosuchdomain.example.com> <v31rj5$o20$1@dont-email.me>
 <87cyp6zsen.fsf@nosuchdomain.example.com> <v34gi3$j385$1@dont-email.me>
 <874jahznzt.fsf@nosuchdomain.example.com> <v36nf9$12bei$1@dont-email.me>
 <87v82b43h6.fsf@nosuchdomain.example.com>
 <87iky830v7.fsf_-_@nosuchdomain.example.com> <v4p0dv$jeb2$1@dont-email.me>
 <87cyof14rd.fsf@nosuchdomain.example.com> <v4s3i8$1cjdr$1@dont-email.me>
 <87frt9zzbm.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 19 Jun 2024 09:37:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="496e798c2f4d7717891a7779c6d418c6";
	logging-data="1962671"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18M0rIqSeN0rqb7PCj768qfIpKKnWw53fI="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:PCz3YvxBGQpgxwvh0Pwd5hzbtYE=
Content-Language: en-GB
In-Reply-To: <87frt9zzbm.fsf@nosuchdomain.example.com>
Bytes: 5516

On 19/06/2024 00:00, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 18/06/2024 02:19, Keith Thompson wrote:
> [...]
>>> I forgot about digit separators.
>>> C23 adds the option to use apostrophes as separators in numeric
>>> constants: 123'456'789 or 0xdead'beef, for example.  (This is
>>> borrowed from C++.  Commas are more commonly used in real life,
>>> at least in my experience, but that wouldn't work given the other
>>> meanings of commas.)
>>
>> Commas would be entirely unsuitable here, since half the world uses
>> decimal commas rather than decimal points.  I think underscores are a
>> nicer choice, used by many languages, but C++ could not use
>> underscores due to their use in user-defined literals, and C followed
>> C++.
> 
> C already uses '.' as the decimal point, though half the world uses ','.

Sure - a programming language has to pick /one/ such option.  And since 
C was written by Americans, they got to choose.  (I don't mind - we use 
a decimal point in the UK too.)  However, if someone from one of several 
European countries sees "1,234" they will read it as 1.234, not 1234. 
This means using a comma as a separator would be a bad idea.

Of course the current multiple uses of commas in C grammar mean that 
commas as digit separators are out of the question anyway.

> That's already US-centric.  ',' is unusable as a digit separator because
> `123,456` already has any of several meanings, depending on the context.
> If it weren't for that issue, I think that using ',' as a digit separator
> would be no more problematic than using '.' as a decimal point.  And C++
> and C23 already use the apostrophe as a digit separator, which is likely
> to be jarring to anyone outside Switzerland.
> 

Yes, but the apostrophe is equally jarring to almost everyone, and 
directly confusing to almost no one.

It might have been better if C++ had used ' for user-defined literals 
(reminiscent of Ada attributes), and then left underscore for a digit 
separator, but that's all history now.

> In any case, as discussed, I'm not proposing an ignorable digit
> separator for hex string literals.
> 

OK.  Digit separators are useful for numbers you read and write 
manually, while these hex string literals are more likely to come from 
generated sources (such as copy-and-paste from a hexdump output).

> [...]
> 
>> I don't see the benefit here.  This is C - the programmer is expected
>> to get the type right, and I think it would be rare to get it wrong
>> (or worse wrong than forgetting "unsigned") in a case like this.  So
>> the extra type checking here has little or no benefit.  (In general, I
>> am a fan of stronger type checking, but it is only important if it
>> catches real errors.)
>>
>> The end result is completely identical to the user - adding
>> "hex(true)" makes no difference to the generated code.  Thus it is
>> just an implementation detail which the user should not have to deal
>> with.
> 
> The point isn't to change the generated code.  The point is to let
> programmers say more directly what they mean: "Treat the contents
> of this file as an array of unsigned char", rather than the existing
> "Treat the contents of this file as a sequence of comma-separated
> integer constant expressions (which, by the way, I'm going to use
> in an initializer for an array of unsigned char)".
> 
> (I don't think either of us is going to change our minds on the
> esthetics.  And yes, that sentence isn't entirely grammatically
> correct.)
> 

Fair enough.