🚀 go-pugleaf

On Sat, 7 Oct 1995, Sam Kendall wrote:

> Well, that assumes you can figure out which program on which machine caused the
> problem.  Then you can rebuild it with a runtime checker, rerun the program,
> and try to reproduce the conditions that caused the crash.  (Even so, your
> checker may miss the error, because most of them miss lots of errors.)

I think you usually can. (There's usually strong evidence, such as seg 
faults... or other mysterious behaviour. Pretty much all "mysterious" 
behaviour can be considered buggy behaviour.)

> This all is necessary because almost nobody deploys or ships programs built
> with a C/C++ checker.  Why don't they?  Because checkers impose large space and
> time penalties.  So C/C++ developers wear a life jacket in the harbor and throw
> it away on the open sea.

Well, the cost for checking in C/C++ programs shouldn't be much more than
for programs written in other languages. Is that an indication of how 
slow other languages are or are you saying that C/C++ programs are 
unchecked because those who use C/C++ want small fast programs?

(Obviously, it is more difficult and thus "costly" to check C/C++ 
programs, but not so much more than for other languages. I guess most of 
the cost is due to the freedom that C/C++ allow.)

- Trung