Fixing programmers

Posted Mar 15, 2019 13:33 UTC (Fri) by anselm (subscriber, #2796)
In reply to: Fixing programmers by rweikusat2
Parent article: Cook: security things in Linux v5.0

What would solve it would be to add another syntactic construct providing an actual multiway conditional, where the code blocks associated with the cases are independent of each other and at most one will be executed.

That would help. But programs using this construct would no longer be C programs. If sticking to a popular and well-understood language standard is of value to you (which makes sense in a large community like the Linux kernel crowd), then this is something not to be thrown away lightly.

OTOH, code that uses the “metasyntactical sort-of language extension” is valid C whether the compiler pays attention to it or not. But if you have a compiler that does pay attention, it's probably a good idea to exploit that, much like we exploit our compiler's paying attention to all sorts of other little things that might otherwise slip us by (think “if (foo = bar) …”).

Like a surgical scalpel, the C programming language is conceptually pretty simple but using it still requires considerable care and attention to detail. I haven't done lots of C programming recently but when I do I'm humble enough to appreciate all the assistance I can get.

Fixing programmers

Posted Mar 15, 2019 15:51 UTC (Fri) by rweikusat2 (subscriber, #117920) [Link] (1 responses)

Linux makes heavy use of gcc extensions already, so, their would be little, additional damage done here. Further, my opinion on this is that C would benefit more from proper multiway conditional than from other, invasive additions like threading support, IOW, if someone would implement support for something like this in a compiler I could use, I'd certainly be using it and expect that the standardized language would eventually catch up.

BTW, I've come to dislike if (a = b) warnings as well: Mistyping == as = is another, extremely rare error and some things will always have to be found and fixed via code rewiev and/ or testing. Algorithmic errors are far more common than any kind of syntax misuse.

Fixing programmers

Posted Mar 15, 2019 17:52 UTC (Fri) by anselm (subscriber, #2796) [Link]

Mistyping == as = is another, extremely rare error and some things will always have to be found and fixed via code rewiev and/ or testing.

You want code review and testing, but you also want reasonable compiler warnings. If a developer is made aware of a “==” vs. “=” typo by a compiler warning while they're writing the code in the first place, the issue doesn't even come up in code review or testing (where it would be more expensive, in terms of developer time, to detect and fix). This is what in security circles we call “defense in depth”.

Algorithmic errors are far more common than any kind of syntax misuse.

Yes, but the syntax problems still exist and are often easier to detect and fix. This is like saying garbage in the street is not important because there are millions of children starving in Africa.