You do not consider it a sign of C's problems in the modern world that so many of its core functions (atoi, atol, atoll, atof, gets, strcat, strcpy, sprintf, etc.) are unsafe and yet still are out there in production and teaching?
Cumbersomeness of these functions is so trivial compared to the problems of C that are real that it's just not worth mentioning them.
Even if these functions disappeared overnight and C acquired the standard library redone using the knowledge accumulated over years, it would not make a difference:
- C is a disaster to write any amount of code in due to the definition of undefined behaviour in the specification.
Not only compilers are free to do anything they want with code that exhibits undefined behaviour, they are unable even to detect undefined behaviour in the code, and hence the only way to write reliable code is to freeze your compiler, toolchain and target OSes: any minor change in any of components (including OS headers) may completely ruin your program.
Ask Linux folks who were bitten by it many times, even though do not have to deal with garbage in vendors' OS headers.
- C is a disaster due to its compilation model. Preprocessor defines wreak havoc on the source code, and it is a backbreaking job to maintain cross-compilability of any large-ish codebase. Forget about trying to cross-compile the whole software with dependencies: this is a full-time job by itself.
- C does not specify sizes of short, int, long and signedness of char. This means any codebase that ever touches these types (and there are OS interfaces that are expressed in them!) is inherently non-portable: every new target means combing over the whole codebase and checking breakages in all arithmetic operations.
There are other underspecified pieces in spec, but this one is just the most salient one.
> in production and teaching
If a teaching resource does not state "C spec has undefined behaviour, and you will have a very bad time if you don't know about it", then it's utter garbage.
> Cumbersomeness of these functions is so trivial compared to the problems of C that are real that it's just not worth mentioning them.
I fully agree! C has many problems, and libc sucking is but one of them (and rather easily worked around). That said..
> Ask Linux folks who were bitten by it many times
A three-decade old project with thousands of developers and millions of lines of code (and heavy reliance on platform & implementation specifics in certain parts) will inevitably at some point along its life get bitten by the rough edges of whatever technology they settle on. Coverage of the few issues they've hit is wildly blown out of proportion, probably precisely because it's so rare that people find these things surprising when it bites them and thus it makes the news.
If Rust gets well adopted in the kernel (as it might), I guarantee that in 30 years, they will have hit its rough edges.
Now if you actually ask Linux folks, they will tell you to flip on -fwrapv and -fno-delete-null-pointer-checks and move on with your life, because whining about these old and solved issues is not productive use of anyone's time.
> C is a disaster due to its compilation model. Preprocessor defines wreak havoc on the source code
Did you ask the Linux folks? They make pretty good use of the preprocessor.
> it is a backbreaking job to maintain cross-compilability of any large-ish codebase. Forget about trying to cross-compile the whole software with dependencies: this is a full-time job by itself
Did you ask the Linux folk? It's hilarious that you mention Linux folk, given that it is one of the most frequently cross-compiled code bases on earth (along with much of the Linux userspace). Btw, I cross compile Linux and various applications regularly at work. In fact, I compile (and maintain) an entire distro with custom kernels for different devices & architectures. And that's not a full-time job. Most of my work is application development, with some driver development now and then.
> - C does not specify sizes of short, int, long and signedness of char.
But it does specify their minimum sizes, which is often all you need. Signedness of char? It sucks, and it is not a big deal. The signed and unsigned keywords exist, btw, if you need a specific sign. If that's too much typing for you, I can sell you typedef. You could ask the Linux folk for advice, they have a few typedefs seem very popular now.
> This means any codebase that ever touches these types (and there are OS interfaces that are expressed in them!) is inherently non-portable: every new target means combing over the whole codebase and checking breakages in all arithmetic operations.
That's not true at all. Minimum sizes are guaranteed, and there are times where using types with implementation defined size is exactly the thing you need because you're dealing with quantities that are inherently related to platform specific ranges. Using these types makes your code more portable, not less portable. I recommend you go ask the Linux folk, or take a look at their source code, which conveniently runs across quite a few platforms.
