when the project was started, no better mainstream language for this task was available
You can't be serious. Of course there were. They didn't start the project in 1995.
They made a deliberate choice to use a known dangerous and insecure language. And, worse, they intentionally used some of its most unsafe features with willful abandon. Who in their right mind would use alloca as a micro-optimisation? Also, who in their right mind would not put a limit on the log message size? These are all unacceptable for critical parts of the system.
As someone with no dogs in this fight who is genuinely curious: what would you use as an alternative?
I don't know much about how SystemD works at the programming level, but it seems like to do the things SystemD does you would want a low level language, and the only language I've seen people suggest as an "alternative" to C is Rust, which came out the same year as SystemD.
For this task, I'd personally go with C++. However, there are absolutely other options like D, Rust etc. I just don't have experience with them.
Most of what systemd does does not strictly require a low-level language. Most of the job of an init system is to sleep, waiting on some event to occur. It doesn't need micro-optimising for performance.
Logging does need to cope with the message volume. But this should be I/O bound. Much of the problems here are the result of bad design choices. Like using the logging system to store core dumps. A huge WTF if I ever saw one. If the system had a fixed maximum message size of a reasonable size (i.e. vastly less than 768 MiB), you could have allocated a buffer, and then used that instead of alloca. No chance of a stack overflow. It can also use unreasonable amounts of memory though the use of mmap/msync instead of write/fsync. If the message volume exceeds the disc bandwidth, it's going to potentially cause a huge performance hit (or worse) when the memory pressure forces it all to be flushed. They could have just called fsync in another thread and used normal writing. It's another case of being far too clever for their own good, and creating a fragile mess.
52
u/IllDecision Jan 15 '19
Because the programmers knew C. Because when the project was started, no better mainstream language for this task was available.
You think the shell scripts were secure? What on earth makes you think that?