[abqexpert]

C2x is expected to gain the char8_t type and almost certainly will not gain any new string handling routines. In the year 2030 I am expecting to still see more rounds of posts comparing string libraries for C. With more than 4 decades of development, we still don't have a great solution to string handling in C.

Every library like this is incompatible and most make slightly odd choices like in this library ownership of the string is denoted by a bit in the info/size field. Not that that is a bad choice or anything, but it is one reason someone might decline to use it and decide to write their own.

The lack of namespacing in C doesn't help, this library chooses str_ as its prefix, which is a bit likely to collide with other libraries. It also makes it harder to try to write libraries that allow for the string library to be switched out.

[Mikhail_Edoshin]

Maybe we don't have a single solution to string handling in C because there's no such thing as a "string". A text editor would need a very different "string" than a typesetting system or an indexing engine.

[josephcsible]

> almost certainly will not gain any new string handling routines

It looks like it'll be getting strdup and strndup.

[abqexpert]

Thanks for that! I hadn't seen it yet, https://en.cppreference.com/w/c/string/byte/strdup says it will be C23 as well.

[EdSchouten]

Fun fact: 'str*' is also reserved by POSIX for future extensions. This means that this library completely collides with POSIX.

[lifthrasiir]

Note that ISO C only reserves /^str[a-z]/ for <string.h> and <stdlib.h>. POSIX's reservation of /^str_/ (note that you are still allowed for identifiers like str8line) is for STREAMS (<stropts.h>) [1], a completely different thing from strings...

[1] https://en.wikipedia.org/wiki/STREAMS

[flohofwoe]

IMHO it's better to ignore "universal string processing" in the C standard completely instead of providing a half-assed and over-complicated solution like in most other languages. String processing isn't exactly a core-competency of C, and never will be, it's better to use a different language for such things.

[saagarjha]

It’s getting memccpy, which is an extremely important function for the creation of a performant, safe string copying method.

[pjmlp]

It is impossible to be safe if size is a function argument that cannot be validated without hardware support.

[saagarjha]

My definition of safety likely differs from yours.

[pjmlp]

My definition of safety means having a size greater than the actual string doesn't turn an innocent looking call into a CVE database entry.

I bet the security industry agrees with my definition.

[bzb6]

Isn’t a function like that trivial to implement?