On Wed, Jun 09, 2004 at 10:37:45AM +0200, Florian Weimer wrote:
> I don't think this is correct. The costs for fixing bugs is higher
> later in the product lifecycle (and the article cites confirming
> data), but these costs might never materialize. Only a fraction of
> all bugs are found, and th
ljknews wrote:
Okay, that's a bold statement. I'd better back it up. If you have a
string-handling library of any kind, someone's going to come up with a
program design that builds a twenty character string for a person's name,
putting first name in the first ten characters, and last name in the
We've talked a lot about secure coding - but is that the whole story?
What about other aspects of systems management - memory management
(consuming memory, memory leaks, etc), process management (DDoS, overloading
systems with processes and threads), DASD management (saturating storage
capacity, c
Damir Rajnovic wrote:
While this is true that only some of the bugs are fixed that fixing can
have unexpectedly high price tag attached. No matter how do you look
at this it _is_ cheaper to fix bugs as soon as possible in the process
(or not introduce them at the first place).
This is true in th
On Wed, Jun 09, 2004 at 03:34:52PM +0100, David Crocker wrote:
> Apart from the obvious solution of choosing another language, there are at least
> two ways to avoid these problems in C++:
>
> 1. Ban arrays (to quote Marshall Cline's "C++ FAQ Lite", arrays are evil!). Use
> classes from the STL, o
