As a place to start discussing why a successor systems language is necessary, comparing string parsing across Rust, Zig, and C? Pretty good place to start, because the problems it introduces are pervasive as the discussion continues.
Magic error values that get globally mutated? Check. Pointers which are either null or exist so you can do arithmetic to deduce a byte length? Check. An almost aggressive distain for handling sum types of even the simplest sort? Check.
Turns out Zig and Rust are whupping the ol' llama on undefined behavior and build processes as well, not to mention memory safety. If only this author had indicated that they might continue writing on the subject...
Where does the article say that those other things are not also big problems? In fact, it specifically says strtol is one example of the things wrong with C. This comment seems needlessly dismissive.
Why complain about a functions though? you can just write your own that does exactly what you want it to do. I don't see how this is a flaw in the language. You could at least mention things like the loss of size information when passing arrays between scopes, that is an annoyance that can be considered as a problem in the language.
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.
"None of the real problems of C are even mentioned."
In your opinion. It may surprise you to know, others might have differing opinions.
At least from how I read it, I completely agree with the post. C makes it hard for programmers to write safe code in general and the author was pointing out one example of this behaviour and what causes it.
The standard library is part of the language. Its also how the language is used, both because the language design encourages it and because people have a tendency to copy how the standard library does things, since you learn to do things how the libraries you use do them.
the build process of C is one of its absolute benefits. Each unit compiles on its own, producing an object file. The fact that people have now started to make header-only libraries makes the story even better! Each function gets a name. No namespaces, classes, scopes, modules, w/e. You can even just declare a function as extern at compile time!
C compilation is not that bad, what makes it atrocious is the preprocessing step.
Show me the large-ish (100K+ LOC) codebase with dependencies that can be cross-compiled, does not come with tons of cruft like autoconf or Meson, and does not require installing reams of software on the host as "libraries", and then we are talking.
While a programming language and ecosystem includes some of the culture, bad code and project structure IMO should not be blamed on C. Modern C projects are a breeze
Not the pervasive undefined behaviour and compilers that become more aggressive every release about breaking previously-working code?
Not the reams of code that assume sizes of integers and signedness of char?
Not the wild build process that makes it awfully hard to actually build anything that has any dependencies whatsoever.
strtol. Damn, what a nuisance!