Re: Ariane5 FAQ

[snarflemike@yahoo.com (Mike Silva)]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1058899826.878512@master.nyc.kbcfp.com>...
> Mike Silva wrote:
> > The code was written to handle every possible value of the parameter
> > properly.  Why you refuse to acknowledge this is a mystery.
> 
> Because this was not the case. The code was written to handle the
> limited range of parameters correctly, by doing a conversion from
> floating-point to 16-bit integer without any guard against overflow.
> 
> When the Ariane 5 data caused an overflow, this same unprotected
> conversion caused an operand fault, which the rest of the system
> then interpreted as the computer itself being broken.

Which was the intended behavior.  There was a project bias that any
unhandled errors were presumed to indicate hardware failure.
> 
> Notice that it's extremely unlikely that the top range of the
> Ariane 4 value exactly corresponded to the maximum integer value
> of the conversion output. That means that there was a range from
> the top Ariane 4 value to the top non-overflowing value where the
> software would have behaved one way, and a range above the
> overflowing value where it would have behaved a different way.

That's right, but it doesn't change anything.  Maybe the Ariane 4
developers were perfectly happy to let those particular "impossible"
values pass through the system, or maybe they should have caught them
as well.  That doesn't change the fact that the system behaved as
designed and intended for the overflowing values.
> 
> The software worked as specified when the input was limited to
> the specified range. Out of that range, the software worked in a
> random, undefined manner.

The behavior of the module over the entire possible range of inputs
was neither random nor undefined.