Date: Tue, 24 Jun 2025 12:56:48 +0000
On 24/06/2025 12:27, Jāāā Gustedt wrote:
> happy to hear that you are now fully into C!
I am glad to be now exclusively here. I think C is an untapped goldmine of improvement to all software everywhere.
>> - Lingua franca results
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3599.pdf
>
> that one doesn't yet seem to be online
Yes you're right. Sorry. I attach it below for now.
>> Which brings me to material not really discussed in earnest since
>> probably covid times, one of which is 'what to do about null
>> terminated strings in C?'
>
> you probably mean that ironically, don't you?
>
> there have been intensive discussions/fights only recently about
> all subjects that you might even remotely associate to the questions
> about string types, `const` qualification and all that.
>
> But since the swamp runs so deep and our discussions are so poorly
> structured, it is depressingly difficult to dig all that up.
I haven't been able to physically attend WG14 meetings in many years, though I expect to be physically at Brno. Due to not being physically present, I have missed many years of 'bar chat'. I don't doubt you speak absolute truth - you've all been discussing this in earnest for years. But it hasn't shown up in papers. Let me show you:
There has been exactly one paper since covid on length prefixed octet arrays which is the one from Martin in 2024:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3210.pdf
Before that, you need to go to 2021 and before.
My notes from my Zoom attendence where N3210 was discussed was that the room felt that spending a size_t on the length prefix was 'too much'. People asked for a variable length prefix to make the overhead more compact.
This is what I am asking now - would WG14 like me to write a paper exploring the overheads of UTF-8 compatible variable length prefixing of variable length octet arrays? I think that for short strings, the overhead would be exactly nil, but it will rise as a percentage of total as strings get longer before shrinking again.
Niall
> happy to hear that you are now fully into C!
I am glad to be now exclusively here. I think C is an untapped goldmine of improvement to all software everywhere.
>> - Lingua franca results
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3599.pdf
>
> that one doesn't yet seem to be online
Yes you're right. Sorry. I attach it below for now.
>> Which brings me to material not really discussed in earnest since
>> probably covid times, one of which is 'what to do about null
>> terminated strings in C?'
>
> you probably mean that ironically, don't you?
>
> there have been intensive discussions/fights only recently about
> all subjects that you might even remotely associate to the questions
> about string types, `const` qualification and all that.
>
> But since the swamp runs so deep and our discussions are so poorly
> structured, it is depressingly difficult to dig all that up.
I haven't been able to physically attend WG14 meetings in many years, though I expect to be physically at Brno. Due to not being physically present, I have missed many years of 'bar chat'. I don't doubt you speak absolute truth - you've all been discussing this in earnest for years. But it hasn't shown up in papers. Let me show you:
There has been exactly one paper since covid on length prefixed octet arrays which is the one from Martin in 2024:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3210.pdf
Before that, you need to go to 2021 and before.
My notes from my Zoom attendence where N3210 was discussed was that the room felt that spending a size_t on the length prefix was 'too much'. People asked for a variable length prefix to make the overhead more compact.
This is what I am asking now - would WG14 like me to write a paper exploring the overheads of UTF-8 compatible variable length prefixing of variable length octet arrays? I think that for short strings, the overhead would be exactly nil, but it will rise as a percentage of total as strings get longer before shrinking again.
Niall
Received on 2025-06-24 12:56:51