> >Even in this case, there's no way to prove your code is not going to
> >crash.
> 
> Sure.  But you can at least prove that all crashes are the result of bugs,
> not merely design "features".

'Proving' something is correct is left as an excercise for the folks who
have way too much time on their hand.  At my previous job (SRI), we have
folks who work full-time trying to prove algorithms.

In general, proving out simple algorithms takes months, when the
algorithm itself took 1-2 hours to design and write.

Another thing is that crashes may have occurred because of invalid
input, invalid output, valid but not expected input, etc...

Again, memory overcommit is only *one* class of bugs that is avoided.
The phrase "can't see the forest for the trees" jumps to mind. :)




Nate

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to