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

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Inspired by the existing syntax for integer and floating-point
hex constants, I propose using a "0x" prefix.  0x"deadbeef" is an
expression of type `const unsigned char[4]` (assuming CHAR_BIT==8),
with values 0xde, 0xad, 0xbe, 0xef in that order.  Byte order is
irrelevant; we're specifying byte values in order, not bytes of
the representation of some larger type.  memcpy()ing 0x"deadbeef"
to a uint32 might yield either 0xdeadbeef or uxefbeadde (or other
more exotic possibilities).

I like the syntax and I’d find it useful.

There’s more to life than byte arrays, though, so I wonder if there’s
more to be said here. I find myself dealing a lot with large integers
generally represented as arrays of some unsigned type (commonly uint32_t
but other possibilities arise too).

In C as it stands today this requires a translation step before
constants can be embedded in source code (which is error-prone if
someone attempts to do it manually).

So being able to say ‘0x8732456872648956348596893765836543 as array of
uint64_t, LSW first’ (in some suitably C-like syntax) would be a big
improvement from my perspective, primarily as an accelerator to
development but also as a small improvement in robustness.

Again, unlike other string literals, there is no implicit terminating
null byte.  And I suggest making them const, since there's no
existing code to break.
>
If CHAR_BIT==8, each byte is represented by two hex digits.  More
generally, each byte is represented by (CHAR_BIT+3)/4 hex digits in
the absence of whitespace.  Added whitespace marks the end of a byte,
0x"deadbeef" is 1, 2, 3, or 4 bytes if CHAR_BIT is 32, 16, 12, or 8
respectively, but 0x"de ad be ef" is 4 bytes regardless of CHAR_BIT.
0x"" is a syntax error, since C doesn't support zero-length arrays.
Anything between the quotes other than hex digits and spaces is a
syntax error.

Would "0x1 23 45 67" be a syntax error or { 0x1, 0x23, 0x45, 0x67 }?

What I'm trying to design here is a more straightforward way to
represent raw (unsigned char[]) data in C code, largely but not
exclusively for use by #embed.

Compilers can already implement #embed however they like, there’s no
need for a standardized way to represent the ‘inside’ of a #embed.

--
https://www.greenend.org.uk/rjk/