Re: [Lit.] Buffer overruns
From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 01/30/05
- Next message: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Previous message: infobahn: "Re: [Lit.] Buffer overruns"
- In reply to: infobahn: "Re: [Lit.] Buffer overruns"
- Next in thread: infobahn: "Re: [Lit.] Buffer overruns"
- Reply: infobahn: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 30 Jan 2005 09:15:12 +0100
infobahn wrote:
> 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.
That different software engineering technologies, including
code review, extensive blackbox and whitebox testing,
'extreme programming', etc. etc. have been employ to advantage
is well known. The problem is that one still doesn't know the
(real) 'absence' of bugs. (Cf also a post of Wagner.) The very
best programmer in the world could err, unless he were divine.
That's the reason of additionally employing (conservative)
security measures in practice if the application is really
critical.
>>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.
Then please kindly illuminate the less knowledgeable here
(me in particular) with concrete stuff in that you rewrite a
couple of examples in the IEEE paper I cited in your sense
and show that what the authors claims there no longer apply.
M. K. Shen
- Next message: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Previous message: infobahn: "Re: [Lit.] Buffer overruns"
- In reply to: infobahn: "Re: [Lit.] Buffer overruns"
- Next in thread: infobahn: "Re: [Lit.] Buffer overruns"
- Reply: infobahn: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
