Didier Kryn <kryn@???> writes:
> Le 04/07/2016 17:20, Rainer Weikusat a écrit :
>> Didier Kryn <kryn@???> writes:
>>> Le 03/07/2016 23:17, Hendrik Boom a écrit :
>>>> On Fri, Jun 24, 2016 at 01:36:14PM -0400, Peter Olson wrote:
>>>>
>>>>> Can I download your compiler that fixes all my mistakes? I could really use such a tool.
>>>> Yes, as a matter of fat you can -- almost.
>>>>
>>>> Two languages I use have the property that once the program gets
>>>> through the compiler, almost all the bugs are gone.
>>>>
>>>> Modula 3.
>>>> OCaml.
>>>>
>>>> Algol 68 is another one, but lgol 68 compilers are as scarce as hen's
>>>> teeth nowdays.
>>>>
>>>>

>>>      Ada also.
>> That's why Ada has been used successfully for the most sensational
>> fireworks:

>

>     Thanks Rainer for this very interesting link. Let me extract the
> root of the explanation:

>
> <<The internal SRI software exception was caused during execution of a
> data conversion from 64-bit floating point to 16-bit signed integer
> value. The floating point number which was converted had a value
> greater than what could be represented by a 16-bit signed
> integer. This resulted in an Operand Error. The data conversion
> instructions (in Ada code) were not protected from causing an Operand
> Error, although other conversions of comparable variables in the same
> place in the code were protected.>>
>

>     So there were functions in this program to convert 64-bit floating
> point to 16-bit integer. This isn't something built in the language
> not even in the compiler.

[...]

>     First error: reuse the code with a different hardware; second
> error: neglect to intercept the exception.

The conversion happened implicitly as part of an assignment and the Ada
runtime raised the exception. It wasn't handled because the (original)
specification demanded to halt the CPU in case of all errors (it was
assumed that software errors wouldn't happen, only hardware failures,
and the 2nd system was supposed to cope with these): The code performed
strictly according to its specification but the specification was
deficient. Programming languages can't protect against that.

The software was then moved as-is from Ariane 4 to Ariane 5 despite it
didn't even serve a purpose there because that was cheaper and "it was
known to work". This caused the latent problem to manifest itself (quite
spectacularly). Programming languages don't held against manically
cost-cutting hardware clowns.

As usual, the big, bad universe was blamed for the failure. Programming
languages don't help against people who won't learn from their mistakes
because they don't think it were there mistakes.