> I think that the OpenBSD team has more than definitively shown that C isn't a problem, programmers' attitudes is the problem.
To err is human, no matter what your attitude. While having the correct attitude can help, this line of argument - that it's the programmer fault and not his tools - is part of the very attitude that causes problems!
Any decent programmer embraces the fact that they'll make faults - and beyond simply trying to improve, they'll also embrace tools that help them compensate. Such as static analyzers. Fuzzing frameworks. Safer programming languages.
Perhaps they'll choose tradeoffs that sacrifice some of these options - I certainly do, coding in C++ all day, a language with at least 40 references to "undefined behavior" in the '03 standard alone. But that doesn't mean those tools aren't worth considering.
> I do agree with them on active reviews, active documentation, and enforcing code hygiene, which prevents the sort of problems that proponents of other languages harp on about when talking about C.
I see zero inherent reason to rely on extreme vigilance by programmers to catch errors that better tooling can catch without having the occasional shared blind spot where 5 programmers all miss an uninitialized variable.
You can help use these to help compensate for C's weakness if that's a tradeoff you need to make, but that's quite an opportunity cost - leaving them with far less time to catch other logic bugs and ship features.
There's a reason nobody preaches about how it's going to be the year of the OpenBSD desktop (and that's not a knock at OpenBSD!)
Vigilance also requires the right knowledge. A coworker recently revealed to me he'd only recently learned that C++ member variables will generally have unspecified values if you don't initialize them. He thought other threads were to blame for garbage values.
Every now and then, I check to see if any of the compilers we're using have added a warning I can enable that will catch leaving members uninitialized after a constructor completes. So I can enable it. And configure it as an error. So everyone who builds the code knows there's a problem. Immediately.
To err is human, no matter what your attitude. While having the correct attitude can help, this line of argument - that it's the programmer fault and not his tools - is part of the very attitude that causes problems!
Any decent programmer embraces the fact that they'll make faults - and beyond simply trying to improve, they'll also embrace tools that help them compensate. Such as static analyzers. Fuzzing frameworks. Safer programming languages.
Perhaps they'll choose tradeoffs that sacrifice some of these options - I certainly do, coding in C++ all day, a language with at least 40 references to "undefined behavior" in the '03 standard alone. But that doesn't mean those tools aren't worth considering.
> I do agree with them on active reviews, active documentation, and enforcing code hygiene, which prevents the sort of problems that proponents of other languages harp on about when talking about C.
I see zero inherent reason to rely on extreme vigilance by programmers to catch errors that better tooling can catch without having the occasional shared blind spot where 5 programmers all miss an uninitialized variable.
You can help use these to help compensate for C's weakness if that's a tradeoff you need to make, but that's quite an opportunity cost - leaving them with far less time to catch other logic bugs and ship features.
There's a reason nobody preaches about how it's going to be the year of the OpenBSD desktop (and that's not a knock at OpenBSD!)
Vigilance also requires the right knowledge. A coworker recently revealed to me he'd only recently learned that C++ member variables will generally have unspecified values if you don't initialize them. He thought other threads were to blame for garbage values.
Every now and then, I check to see if any of the compilers we're using have added a warning I can enable that will catch leaving members uninitialized after a constructor completes. So I can enable it. And configure it as an error. So everyone who builds the code knows there's a problem. Immediately.
So far, no dice.