How many backwards incompatible variations of C++ std::string have there been, simply in terms of the standard (not extensions). Two? Three?
glibc has been turning their nose up at strlcpy(3) for literally 20 years, and yet still doesn't provide a comparable one-liner alternative that guarantees to always leave a NUL-terminated string behind (i.e. doesn't leave a loaded gun lying around).
A good string interface is impossible to pin down because a "string" is the anti-thesis of a proper data structure. C dipped its toes in the better string library waters with Annex K, which saw almost no uptake; even the original sponsor, Microsoft, never shipped a complete implementation. C would be wise to avoid chasing the mirage of a better string library. In general if you're thinking in terms of "strings", C is the wrong language. C being an inconvenient language for programming with that mindset is a good thing.
(I would love to see strlcpy added, but the fact it's so divisive is maybe a strong hint that there's no way to placate a substantial minority of people, not even the most pragmatic of users. Anything involving the str* API is a lose-lose at this point.)
What C really needs are some primitives for bounded arrays and slices. There are some very good, very simple proposals out there, but no compiler vendor has actually shipped them and the C committee has been burned several times before by standardizing de novo interfaces.
I guess mostly because they decided that in what concerns improving Windows system programming safety they were better moving everything into C++ and let others keep bothering with C.
And nowadays their are eyeing into the C#, C++ (with Core Guidelines analyzers) and Rust.
The exception being Azure Sphere, but I bet they will eventually add Rust there, as using C taints the security story of Azure Sphere.
The resistance among C devs to move away from micro-optimize every line of code while writing it down is too big to ever adopt one of those primitives for bounded arrays and slices.
Leading to solutions like ADI enabled SPARC Solaris, or the future Android devices that will be coming with ARM memory tagging enabled.
snprintf(destination, sizeof(destination), "%s", source);
?The size argument is an int, not size_t, so there are arithmetic overflow problems.
The return value is also an int, creating underflow and overflow hazards, though the degree to which this is a problem, and the extent to which it's a feature, vary. Everybody has a different opinion about how truncation should be signaled, if at all.
[1] Because glibc snprintf uses (or at least used) its stdio FILE interfaces for implementing snprintf, and it conditionally uses malloc for initializing a temporary FILE object.
It's a pretty hard task to tackle libc (not just string functions, obviously), maybe for the same reason there're only a few libc implementations (support full dynamic linking).
To give you an idea, here's a chip used by at least one of the products developed by the author:
https://www.st.com/en/microcontrollers-microprocessors/stm32...
16KB of ram. You're not going to see any linking on this because you're probably running everything in a single address space anyways.
> Part of libc such as pthread is very hard, and so does the dynamic linker.
What does this mean? I'm having trouble parsing this as English much less making sense of the argument :)
> It's a pretty hard task to tackle libc (not just string functions, obviously), maybe for the same reason there're only a few libc implementations (support full dynamic linking).
Why does libc ship with string functions in the first place? What is special about strings that they are included in libc while other data structures (to my knowledge) are not? Presumably you don't need strings to implement malloc or other parts of libc?
Thread-Local Storage:
- function names limited to 6 characters (because of compiler/linker memory limits at the time?)
- non-reentrency of many functions (strtok(), errno...)
- dangerous string manipulation functions (see the various iterations of strcpy())
- and so much more...
Of course, I'm missing the point. Libc continues on because it's standard and backwards-compatible, and lets you leverage 50 years of software ecosystem.
Nevertheless, I'd love to see what a modern clean-slate implementation might look like. I'm sure there'd be much disagreement about what warrants replacement and what doesn't ;)