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