Re: [Lit.] Buffer overruns

From: infobahn (infobahn_at_btinternet.com)
Date: 01/30/05 

Date: Sun, 30 Jan 2005 05:35:29 +0000 (UTC)

Mok-Kong Shen wrote:
>
> If further improvement is not required, then that's
> defacto perfection, isn't it? The crucial issue is
> how do you achieve that state, given, among others,
> the falliability of programmers.

Let's do a worked example. The figures are made up, of course, but
I have tried to make them realistic. If anything, I've erred on the
conservative side. (I think programmers can write better code than
I've assumed here. I think reviewers can find more bugs than I've
assumed here.)

Consider a programmer who can write code that is 99% bug free (say,
he makes 1 mistake per hundred lines, on average). This same
programmer can spot, say, three bugs in five, in other people's code.

Take a 100,000 line program, written by 10 such programmers. On
average, it will have 1000 bugs in it. Each 10000 lines will have
100 bugs in it, and will be reviewed by 9 people, independently.
The probability of any one bug not being spotted by at least one
person is therefore (2/5)^9, or 0.00026. That's about 1 in 4000.

If you want safer odds, hire better programmers.

> Do you agree that buffer overruns and
> other software loopholes exploited by hackers are a
> existing 'fact' in the practice?

Yes, this has never been under dispute.

> You consider that for
> a software developed using a 'proper process' such
> shouldn't occur.

That's right. It follows that most software sucks. This also
has never been under dispute.

> It follows then that all these 'weak'
> software exploited/exploitable by hackers are not
> developed using a 'proper process', right?

Right.

> One could
> accept that reasoning. But this 'knowledge' doesn't
> help the society,

Really?

> unless you have a practically
> (not simply theoretically) realizable recipe to enable
> all manufacturers of safety critical software to use
> such 'proper process',

Design it properly.
Code it properly.
Debug it properly.
Review it properly.
Test it properly.

Nothing new here.

> given the hard 'real-world'
> constraints that they have (the impossibility of having
> good programmers and reviewers 'in practice' such that
> the software released is guaranteed to be bugfree,
> etc. etc.)

Ah, you want high quality output for low quality input? Dream on.

Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... >>the falliability of programmers. ... I think reviewers can find more bugs than I've ... >>a software developed using a 'proper process' such ...
    (sci.crypt)
  • Re: Overview Of New Intel Core i7(Nehalem) Processor
    ... programmers raving about Java and stuff, ... Programmers who really enjoy working with computers ... So the ideal programming language is Cobol, ... automated checker to find my bugs. ...
    (sci.electronics.design)
  • RE: Update: Web browsers - a mini-farce (MSIE gives in)
    ... point is that an HTML renderer should not be designed for inputs from ... In general, programmers can protect against ... classes of bugs without prior understanding of those bugs. ... You don't have to understand how to exploit a buffer overflow in order to ...
    (Bugtraq)
  • Re: How does this make you feel?
    ... > [listing system programmers, app programmers, end users] ... bug and feature since they are sometimes synonymous. ... > Bugs that are visible all the way up to the end user: ... > 1% because the big limiter is memory latency. ...
    (comp.arch)
  • Re: C / C++ skills
    ... but the pitfalls of so called safe languages are not that different. ... The only way to be sure of the absence of bugs is to design software to ... the odd operator precedence of C, tripping up new programmers. ... But yeah, a well-worded coding standard, and a culture that cares about it ...
    (comp.arch.embedded)