People use the tools they have available and understand. Rust, at the time this bug was introduced into sudo, was barely a year old, and hadn't even released 0.1 yet.
Also, the sarcasm in your comment really doesn't help your message.
I have been advocating against C since comp.lang.c days, no need for lessons about how to market something that the audience obviously isn't interested into paying attention.
The first systems programming language that would prevented this kind of exploit was written in 1961, 10 years before C was invented.
Firstly, the constant nagging (of the kind appearing here, and often on other HN threads) against C and family are obnoxious. Any language will have both downsides and upsides and picking this one "flaw" in C and then pretending like it's a reason that C absolutely shouldn't be used is absurd.
Secondly, the Sudo code in question seems to be a result of a poor or nonexistent design process (which also seems consistent with Sudo's horrific bloat of features), so this isn't a good example for preaching against C.
Slightly off-topic, but FTR I view C as somewhat crippled and C++ as an easy to misuse Lovecraftian monstrosity (but much more powerful and useful than C), and I suspect Rust's way of forbidding the user from making memory errors is more trouble than it's worth.
On top of risks common to any language (which type systems are starting to work on), pointer arithmetic adds uniquely catastrophic risks that are no longer justified by big gains at runtime. People keep thinking they can get away with it, but we have decades of proof that they’re wrong. We can afford tools that don’t randomly explode.
First, C has been known to never have been a good option for systems programming, and has UNIX adoption to thank for its existence, instead of having faded into the history of systems programming languages.
Quote from C.A.R Hoare at his Turing Award speech in 1981:
"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
This is what is missing to force C to finally stop being the JavaScript/PHP of systems programming, liability for exploits with hefty sums.
Second, I keep being told that it is possible to write perfectly safe code in C, it is just a matter of using the tools.
From your assertion, it appears the sudo project has some learning to put into place then, because code reviews weren't enough to prevent this exploit.
C++ tries to gently dissuade the user from making memory errors and still often fails. See: unique_ptr, std::move, ctors, dtors, move mechanics, rule of 0/3/5, etc, It's just more complicated, less elegant, and a pain in the ass.
Also, the sarcasm in your comment really doesn't help your message.