tl;dr sudo parses /proc, fucks up
I think that sells it a little short. There’s something to be said about a system design where parsing strings in /proc is a thing, how A leads to B leads to root, etc.
It also illustrates why procfs in and of itself is bad for security.
I’d take it more that hard to parse formats due to a poor choice of how to handle field separators that appears in your data lead to bugs. This particular parsing issue is one I’ve run into myself.
Really it illustrates that plain text (byte sequences) as popularized by unix is a poor interface format. Unfortunately it continues to be popular because C’s retrograde type system and poor literal support discourage those who still write C from using anything better.
This really has nothing to do with C, and the language blaming is unwarranted. There are perfectly good (C) APIs that do not involve parsing text, and such an API could have been used here. But some people think parsing text is still the way to go.
[Comment removed by author]
The proper solution would be to expose an API from the kernel.
System control (sysctl) nodes would be the preferred route.
For most things it’s very difficult to express a good API without sum types. In C you can’t even fake them with polymorphism and the visitor trick.
Human readable formats vs machine readable formats, really…
What does OpenBSD do there?
In general, sysctl.
Argh! I hope this leads to people being more open to using ASCII separators as delimiters.
You can put ASCII separator control codes in file names too…
True, I suppose. Although I’ve never seen that, whereas spaces are extremely common.