|Re: inlining + optimization = nuisance bugs firstname.lastname@example.org (Luddy Harrison) (1998-09-29)|
|Re: floating point, was inlining + optimization = nuisance bugs email@example.com (David Chase) (1998-10-04)|
|Re: floating point, was inlining + optimization = nuisance bugs firstname.lastname@example.org (Toon Moene) (1998-10-04)|
|Re: floating point, was inlining + optimization = nuisance bugs email@example.com (1998-10-05)|
|From:||firstname.lastname@example.org (Gene Wirchenko)|
|Date:||5 Oct 1998 20:46:05 -0400|
|Keywords:||errors, design, arithmetic,|
David Chase <email@example.com> wrote:
>Placing such an emphasis on testing seems a bit like admitting defeat
>(from the point of view of "good design" and "program proof"), but in
>my experience no amount of careful design and program proof (as if
>anyone proved significant programs correct, with the notable exception
>of the people at CLI) can protect you from the typical blizzard of
>typos and thinkos committed by people working in a hurry. If it isn't
>tested it doesn't work (no matter who designed it), and good testing
>is difficult and expensive even without gratuitous compiler-
It might be your bug and it might be a compiler or run-time bug.
As if the end user will care when you forget to test.
I recently found out that the messagebox() function in Microsoft
Visual FoxPro 5 silently truncates the string to be displayed when it
is longer than 512 characters. This "feature" isn't documented. The
way to find out about it is to do it. As I did. I hadn't tested this
after adjusting the message. Ouch!
Return to the
Search the comp.compilers archives again.