Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

["James S. Rogers" <jimmaureenrogers@worldnet.att.net>]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305161748.1735fc32@posting.google.com...
> C would catch that in a vanilla situation (assigning
> an integer to a string pointer), so I
> assume the situation was far from vanilla, in
> which case it is possible for things like
> that to happen in Ada.

This is an interesting statement. You say that with no technical
detail.

One of the big differences between the Ada type system and the
C/C++/Java type systems regarding numeric types is the complete
lack of implicit conversion between numeric types in Ada.

My experience is that implicit language conversions make coding
very convenient. They also make coding somewhat unpredictable.
The worst example of that, in my experience, is PL1.

Another insidious problem with C style numerics is value overflows.
C, C++, and Java do not detect or flag numeric overflows or
underflows. For instance, a Java byte has a range of values of
-128 to 127. Calculations that overflow those ranges produce a
value wrapping. This behavior is appropriate for modular or
unsigned types. It is not appropriate for signed types.

The smaller integer types are provided to allow the programmer to
conserve memory. This conservation comes at a price; the need to
guard against value overflows. The result is that int and long are
generally used because it is easier to excuse a little extra memory
usage than to explain erroneous calculations.

I am sure you would agree that a good programmer will carefully
analyze the problem domain before using a short or a byte type.
The problem arises during program maintenance, when the
requirements change and a value needs to handle values beyond
the range of a short or a byte. The program will still compile and
run without flagging errors. The results of calculations will, however
reveal serious errors.

Ada's strong typing allows you to define small types with limited
value ranges. On the surface this may seem to be just what you
get from the C family of languages. Strong typing does make a
difference here. Ada signed numeric types do not exhibit value
roll over. Instead, a run-time exception will be raised if an out of
range value is calculated. To fix the maintenance problem described
above in Ada you simply replace the original numeric type definition
with one that fits the new requirements. This typically means changing
one line in one file.

Fixing the problem in C requires a much longer search through the
source. You must change all the variable declarations in the file
containing the function(s) that need to use the larger type in a
calculation. You then need to change all the parameters passed
to those functions, particularly if they are passed by reference.
All those changes require a very carefully crafted and executed
test suite to confirm that the job was done properly.  Even the
testing is simplified due to the Ada strong type model.

Jim Rogers