Re: [Lit.] Buffer overruns

From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 01/22/05 

Date: Sat, 22 Jan 2005 18:43:24 +0100

Douglas A. Gwyn wrote:
> Trevor L. Jackson, III wrote:
>
>> So a reduction in the scope/prevalence/incidence of the problem is
>> uninteresting? Given that the better is the enemy of the good,
>> "solving" the problem is an enemy of "reducing" the problem.
>
>
> To the contrary: By concentrating your efforts on
> problem "reduction" you don't reduce the *incidence*
> of the problem, just (perhaps, depending on many
> contextual factors) the *consequences* of some of
> the incidents. Yet that is widely advertised and
> believed to be "addressing" the problem, with the
> likely effect of reducing resources applied to
> eliminating the possibility of any occurrence of
> the problem.
>
> A comparable effort properly applied to eliminating
> the incidence altogether would have a much greater
> practical payoff.
>
>> 1. Does automation of error detection reduce the problem or not?
>
>
> Not significantly. (Only to the extent that it might
> aid in catching errors that would otherwise not be
> caught during the development cycle, and if decent
> methodology has been used there will be few if any
> buffer-overrun bugs matching that description.)
>
>> 2. Given the lower reliability of humans, even well trained ones, on
>> what basis should any project leader prefer manual techniques of error
>> prevention/detection to automated techniques?
>
>
> Because the technology to address the actual
> problem where it actually occurs does not yet
> exist in a practical automatic form. Various
> automation tools can be applied in the process
> of doing this job right, but ABC is relatively
> insignificant.
>
> Relying on ABC for this reminds me of that
> story about the lost key and the streetlight.

You have till now repeatedly negated the benefits of
some features of the safer PLs in comparison to C. I
suppose it is perhaps illuminating to apply the same
sort of arguments to compare C with assembler or even
raw machine coding. According to the same logic as that
of yours, if only the project is properly managed and
the programmers are careful enough etc., there wouldn't
also be problems with pure assembler or raw machine
coding and further issues that couldn't be resolved
by such coding couldn't be resolved by programming in C.
(After all, a C program is in any case transformed to
a piece of machine code before being executed.) So
please tell us what's the justification of using C in
the first place? (If could state any such justification,
then one would be able to similarly argue for the use
of safer PLs in safety-critical applications instead
of C.)

M. K. Shen
---------------------------------
http://home.t-online.de/home/mok-kong.shen

Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... > sort of arguments to compare C with assembler or even ... > raw machine coding. ... > the programmers are careful enough etc., ... > also be problems with pure assembler or raw machine ...
    (sci.crypt)
  • Re: Is necessary to switch to C++ or some object-oriented language?
    ... i still a newbie but the difference is that i live with ... programmers, here on comp.lang.c, rather than with academics. ... must learn a more modern and object-oriented language. ... you need to solve problems by coding, ...
    (comp.lang.c)
  • Re: Replacing Delphi developers
    ... Good coding practice is one of those things that many people take on ... gained with age, not from sitting in lectures, nor from the choice of some ... attribute and must be learnt from other programmers, by hanging out on a ng, ...
    (comp.lang.pascal.delphi.misc)
  • Re: Writing bulletproof code
    ... >> Efficiency is part of good coding. ... the 'C' language and the libraries. ... >> where most programmers seem to go wrong, ... >> triple checking is more important than efficiency. ...
    (comp.programming)
  • Re: Replacing Delphi developers
    ... Good coding practice is one of those things that many people take on ... the first step is to provide a fun ... > attribute and must be learnt from other programmers, by hanging out on a ng, ... While i agree that learning which has, ...
    (comp.lang.pascal.delphi.misc)