Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Fri, 14 Jun 2024 23:39:18 +0100
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <v4igql$32qts$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me>
 <00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com>
 <v2lji1$1bbcp$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 15 Jun 2024 00:39:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="70a9fc796b84cb08329413872ec51cfa";
	logging-data="3238844"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18UNxoZjtV6v91GHYRRfyub"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:HaHtJCltzF0X9dEPx5yKGfNNVqw=
In-Reply-To: <87v82b43h6.fsf@nosuchdomain.example.com>
Content-Language: en-GB
Bytes: 3724

On 14/06/2024 22:30, Keith Thompson wrote:

> Now that it's too late to change the definition, I've thought of
> something that I think would have been a better way to specify #embed.
> 
> Define a new kind of string literal, with a "uc" prefix.  `uc"foo"` is
> of type `unsigned char[3]`.  (Or `const unsigned char[3]`, if that's not
> too radical.)  Unlike other string literals, there is no implicit
> terminating '\0'.  Arbitrary byte values can of course be specified in
> hexadecimal: uc"\x01\x02\x03\x04".  Since there's no terminating null
> character and C doesn't support zero-sized objects, uc"" is a syntax
> error.
> 
> uc"..." string literals might be made even simpler, for example allowing
> only hex digits and not requiring \x (uc"01020304" rather than
> uc"\x01\x02\x03\x04").  That's probably overkill.  uc"..."  literals
> could be useful in other contexts, and programmers will want
> flexibility.  Maybe something like hex"01020304" (embedded spaces could
> be ignored) could be defined in addition to uc"\x01\x02\x03\x04".

That's something I added to string literals in my language within the 
last few months. Nothing do with embedding (but it can make hex 
sequences within strings more efficient, if that approach was used).

Writing byte-at-a-time hex data was always a bit fiddly:

     0x12, 0x34, 0xAB, ...
     "\x12\x34\xAB...

It was made worse by my preference for `x` being in lower case, and the 
hex digits in upper case, otherwise 0XABC or 0Xab or 0xab look wrong.

What I did was create a new, variable-lenghth string escape sequence 
that looks like this:

   "ABC\h1234AB...\nopq"     // hex sequence between ABC & nopq

Hex digits after \h or \H are read in pairs. White space is allowed 
between pairs:

   "ABC\H 12 34 AB ...\nopq"

The only thing I wasn't sure about was the closing backslash, which 
looks at first like another escape code. But I think it is sound, 
although it can still be tweaked.