Re: Buffer overflow Article - CACM

["robin" <robin_v@bigpond.com>]

Christopher Browne wrote in message ...

>Something that is only approximately correct but that is super-fast
>may, in cases where time or computational effort *are* at a premium,
>be preferable to a slower "correct all the time" program.
>
>The trouble with formal verification methods is that they consume time
>(for the analysis work) when you may well discover that the problem
>wasn't specified well enough in the first place for formal
>verification to actually do any material good.
>
>Having super-well-specified problems is extremely necessary when doing
>"rocket science;" if it costs $1B to fire off a rocket, and you don't
>get a second chance, it's necessary to do whatever up-front effort is
>required to make sure the problem is super-well-specified.
>
>But there are a lot of cases where that level of effort is not
>warranted, and it's NOT worth getting "super-detailed, super-correct"
>specifications, and it's NOT worth various of the efforts.
>
>Where the CACM article has some things *right* is that there are
>plenty of systems where it would be way too costly to reimplement them
>in a buffer-overflow-immune language.  People are not going to redo
>everything in PL/1 or Ada just because they have better specified
>string types.  They don't have time.

Perhaps the message of the article is that for future
projects those languages would provide better outcomes.

>--
>(format nil "~S@~S" "cbbrowne" "ntlug.org")