Re: Boeing and Dreamliner

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Dave Thompson wrote:
> On Mon, 30 Jun 2003 11:55:00 -0400, "Warren W. Gay VE3WWG"
> <ve3wwg@cogeco.ca> wrote:
> [snip]
> 
>>I would disagree with your position on the basis that even where code
>>is carefully scrutinized, within Ada you have the advantage of builtin
>>language features to check areas that you might neglect (while developing
>>and testing at least, prior to checks being turned off).
>>
>>For example, where a short (16 bit integer) in C/C++ might hold the
>>value -32768, and be negated and assigned to a short result, this
>>operation might be undefined (I am not sure if any newer standard like
>>C99 addresses this). On some implementations at least, that result is
>>silently set to 0, which clearly is incorrect! In Ada, this cannot be
>>ignored without deliberately working around it (or turning the checks
>>off).
> 
> In C and C++ short is _at least_ 16 bits, but may be more, and
> negation (prefix '-') is done after (at least virtually) applying the
> integral promotions, which includes short to int.
> 
> If int is also 16bit 2sC capable of representing -32768 but not 
> +32768, which is legal but increasingly rare, then the negation 
> is overflow and undefined behavior, which may theoretically do
> anything, and in particular no check or diagnostic required.
> This is the same in C89, C99, and C++98.  In practice it is 
> expected that if the platform has a negate (or subtract) 
> instruction or function that works correctly for nonoverflow 
> cases, the C compiler will just use it and accept whatever 
> it does for overflow, which is typically either a wrong value, 
> almost always a wrapped value, or some trap or signal.
> 
> If short is 16bit but int is larger (e.g. 32bit) then the (promotion
> and) negation is well-defined, and the narrowing assignment to short 
> produces an implementation-defined result in C89 or C++98, 
> and either an implementation-defined result or an implementation-
> defined signal in C99; implementation-defined means it must be 
> documented.  Still no check or diagnostic is required, unless the 
> implementor chooses to doument such, but it is required that 
> you either get some value or in C99 only some definite signal 
> which (presumably?) can be caught by a signal() routine although not
> necessarily recovered/resumed; you may not get arbitrary weirdness or
> crash.  FWTW.
> 
> These cases can be distinguished, if necessary, at or before compile
> time by checking the values in <limits.h>.
> 
> - David.Thompson1 at worldnet.att.net

So what this says, in the end, is that it is up to the programmer
to make these "checks" and to "do the right thing".

This is clearly one specific area that Ada has a
advantage in safety. Unless you run/test your code
with the checks deliberately turned off, you will discover this
little gem immediately (assuming that you encounter the right
data, that is). Conversely, in C/C++, this "undefined
behavior" may go completely unnoticed, until it has a disasterous
side effect somewhere else down the line.

This is the precise scenario I ran into when porting some C code
into Ada some time ago. The SOX C code was oblivious to this
"error", but the Ada code that I ported caught it.  So this
was a real example of the C programmer failing to "do the
right thing", and Ada forcing _this_ programmer to
do "the right thing." ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg