Le 08/07/2016 15:25, Rainer Weikusat a écrit :
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,
I tell that, for anyone who has a little of experience with Ada,
the concepts of a 64-bit floating point doesn't exist and the concept of
a 16-bit integer is only used when dealing with matching with an
hardware interface, which was apparently not the case here. These
concepts are imported from cpu hardware or from another language. Ada
separates the programmer from implementation concerns. The conclusion I
draw from this report is that the author of the report thinks with
concepts which are foreign to the language and it seems the author of
the program did the same.
My personnal understanding is this was a total jeopardy: the
company in charge produced a code in Ada because it was a requirement,
but they didn't hire a skilled Ada programmer; nobody reviewed the code,
which was translated from another language to Ada, with a very poor
result; and even the authors of the report lack a basic knowledge of the
language.
And I insist: there are no such loosy things as implicit
conversions in Ada, whatever the word you use to express the concept.
You consider natural to program with short int or double and have
implicit conversions in pretty much every expression and assignment. All
of this just doesn't exist in Ada. You can force (you don't even imagine
down to which details) the way a variable is implemented, but you do it
when it makes sense.
For what regards raising an exception, what else could be done? At
least it triggered autodestruction, which is for sure better than
heading to a random direction. This is also part of Ada's rationale:
always check everything (as much as possible at compile time, else at
run time) and never silently ignore an error because it could produce
unpredictable effects; raising an exception is always better. You can
catch exceptions at some higher level of course - if you know how to
recover.
Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
