4 ms·

Why not just call it "Rules for Writing Code"? Who would ever, for example, consider checking the return value of some function but then think "ah, this isn't

by vbtemp 10y ago

Why not just call it "Rules for Writing Code"? Who would ever, for example, consider checking the return value of some function but then think "ah, this isn't safety critical, I'm just skip writing a quick _if_ statement and then leave this as a place that mysterious bugs can arise"? Same thing with assertions.

4ad 10y ago
Because these rules have a cost, and sometimes the cost is not worth it for non-safety critical code. It would be a PITA for general purpose code to avoid all dynamic memory allocation.
- vbtemp 10y ago
  With the sole exception of item (3) in that list (pertaining to dynamic allocation), which others carry a cost?
  - jhomedall 10y ago
    Not allowing recursion makes functional programming impossible. Giving all loops a fixed upper bound comes at a cost to code readability (consider the example of traversing a linked list, as given in the article).
pjc50 10y ago
Have you met programmers? Less snarkily, there are billions of lines of production code that don't check return values for malloc(), printf(), and so on because those failures are extremely rare and difficult to handle sensibly. Banning dynamic allocation would ban large areas of programming language - Lisp, Python, Javascript, and so on.
- kazinator 10y ago
  Even if you check the return value of malloc, that doesn't help when virtual memory is overcommitted. Malloc gets a valid pointer from mmap, but accessing the memory later crashes. A system OOM may actually show a soft behavior, whereby the whole system thrashes more and more until it grinds to a halt. Whatever your program does is futile and irrelevant. To QA the program for how it handles null out of malloc, you need to tweak the setup: disable overcommit and simulate low memory conditions. (Or even just switch to an alternative allocator that simulates failures.) Checking the result of malloc for null is of course good for maximal portability: your code can be reused where the check actually means something. Checking for null and not testing that logic is almost no better than not testing at all (in keeping with the general hypothesis that untested code is junk).
closeparen 10y ago
1) Some languages have tail call optimization and sometimes recursion is the clearest way to express an idea. 2) Requiring a fixed upper bound when iterating a collection of objects is a direct contradiction of the ZOI rule[0]. Most programs should not place arbitrary boundaries on the number of objects they'll operate on. This is better adapted to systems with relatively fixed databases and a predictably low volume of operator and sensor input (i.e. flight management computers, train control systems) more than internet services. 7) "For this reason, most coding guidelines for safety critical software also forbid the use of all ansi standard headers like string.h, stdlib.h, stdio.h" should speak for itself. 9) Is pretty C/C++ specific. [0] https://en.wikipedia.org/wiki/Zero_one_infinity_rule https://en.wikipedia.org/wiki/Zero_one_infinity_rule
- pjc50 10y ago
  > Most programs should not place arbitrary boundaries on the number of objects they'll operate on I think this can be argued both ways. The classic stateless pipe programs, sure, they can take as many lines as you want. User-facing programs? It can be worth imposing fairly small limits just so you don't have to worry about pathological behavior and security risks. (What happens if someone pastes a million lines of text into a small box, etc)
AnimalMuppet 10y ago
I'm writing a quick program that's supposed to compute something and print out the answer. I don't check the return value of printf(). Why not? 1. printf almost never fails. If it does, I'm just going to re-run the program. If that doesn't work, I'll reboot and then re-run. On average, I waste less time with that approach than with checking the return value of printf. 2. If printf fails, what am I going to do? Print out an error message? But that might fail, too. Log something? That could also fail. Should I check the return values of those attempts, too? But safety-critical code is usually not calling printf - it may not have a conventional output device at all. (It should have some mechanism for alerting the operator if there are failures, though.)

by vbtemp 10y ago

4ad 10y ago

Because these rules have a cost, and sometimes the cost is not worth it for non-safety critical code. It would be a PITA for general purpose code to avoid all dynamic memory allocation.

vbtemp 10y ago
With the sole exception of item (3) in that list (pertaining to dynamic allocation), which others carry a cost?
- jhomedall 10y ago
  Not allowing recursion makes functional programming impossible. Giving all loops a fixed upper bound comes at a cost to code readability (consider the example of traversing a linked list, as given in the article).

pjc50 10y ago

Have you met programmers? Less snarkily, there are billions of lines of production code that don't check return values for malloc(), printf(), and so on because those failures are extremely rare and difficult to handle sensibly. Banning dynamic allocation would ban large areas of programming language - Lisp, Python, Javascript, and so on.

kazinator 10y ago
Even if you check the return value of malloc, that doesn't help when virtual memory is overcommitted. Malloc gets a valid pointer from mmap, but accessing the memory later crashes. A system OOM may actually show a soft behavior, whereby the whole system thrashes more and more until it grinds to a halt. Whatever your program does is futile and irrelevant. To QA the program for how it handles null out of malloc, you need to tweak the setup: disable overcommit and simulate low memory conditions. (Or even just switch to an alternative allocator that simulates failures.) Checking the result of malloc for null is of course good for maximal portability: your code can be reused where the check actually means something. Checking for null and not testing that logic is almost no better than not testing at all (in keeping with the general hypothesis that untested code is junk).

closeparen 10y ago

1) Some languages have tail call optimization and sometimes recursion is the clearest way to express an idea. 2) Requiring a fixed upper bound when iterating a collection of objects is a direct contradiction of the ZOI rule[0]. Most programs should not place arbitrary boundaries on the number of objects they'll operate on. This is better adapted to systems with relatively fixed databases and a predictably low volume of operator and sensor input (i.e. flight management computers, train control systems) more than internet services. 7) "For this reason, most coding guidelines for safety critical software also forbid the use of all ansi standard headers like string.h, stdlib.h, stdio.h" should speak for itself. 9) Is pretty C/C++ specific. [0] https://en.wikipedia.org/wiki/Zero_one_infinity_rule https://en.wikipedia.org/wiki/Zero_one_infinity_rule

pjc50 10y ago
> Most programs should not place arbitrary boundaries on the number of objects they'll operate on I think this can be argued both ways. The classic stateless pipe programs, sure, they can take as many lines as you want. User-facing programs? It can be worth imposing fairly small limits just so you don't have to worry about pathological behavior and security risks. (What happens if someone pastes a million lines of text into a small box, etc)

AnimalMuppet 10y ago

I'm writing a quick program that's supposed to compute something and print out the answer. I don't check the return value of printf(). Why not? 1. printf almost never fails. If it does, I'm just going to re-run the program. If that doesn't work, I'll reboot and then re-run. On average, I waste less time with that approach than with checking the return value of printf. 2. If printf fails, what am I going to do? Print out an error message? But that might fail, too. Log something? That could also fail. Should I check the return values of those attempts, too? But safety-critical code is usually not calling printf - it may not have a conventional output device at all. (It should have some mechanism for alerting the operator if there are failures, though.)