Re: [Lit.] Buffer overruns
From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 12/17/04
- Next message: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Previous message: karl malbrain: "Re: [Lit.] Buffer overruns"
- In reply to: all mail refused: "Re: [Lit.] Buffer overruns"
- Next in thread: Bryan Olson: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 17 Dec 2004 03:15:57 +0100
all mail refused wrote:
> Mok-Kong Shen wrote:
>
>>also commonly employed. Further, one could parallelly run
>>duplicated programs (on different hardware) that are coded
>>by different people and have the results determined by
>>majority consensus.
>
>
> This tends to fail when they've worked from the same spec
> and/or learned programming the same way.
>
> A 1990s article in "Nuclear Engineering International" had
> an illustration where 4 teams had to implement something
> specified in English (concerning real-time response to a
> measured water level) and they produced 4 different behaviours.
Yes, anything could fail in this non-perfect world. The
specification problem couldn't be dealt with within the
framework of PLs. There are certain specification
methodologies, though, that are intended to help in that.
If doable, one should employ different algorithms for
the same task. The human thinking problem you indicated
should be taken into consideration but there is no
'fundamental' solution, I am afraid, though one may be
able to do something in training and management. But
anyway a scheme that employs cross-checking should be
better than one without such.
M. K. Shen
- Next message: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Previous message: karl malbrain: "Re: [Lit.] Buffer overruns"
- In reply to: all mail refused: "Re: [Lit.] Buffer overruns"
- Next in thread: Bryan Olson: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
