Re: Hex string literals (was Re: C23 thoughts and opinions)

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.