Re: Ada News Brief

[kilgallen@eisner.decus.org (Larry Kilgallen)]

In article <dewar.845384950@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Keith said
> 
> "I'm not sure where this statement came from, but it's not quite correct.

As I read it, it came from a press release, so expectations should be low.

> 2. Bugs in the new Ada 95 compiler. As OCS systems pointed out, for at 
>    least some time to come, every Ada 95 compiler will have some bugs.

Folks who spend their life dealing with software quality will say that
every Ada 95 compiler will have bugs (defects) _forever_, just as with
any other program.  Priority is properly ascribed to those defects that
will be found by a user.  That is hard to measure in general, but as a
special case one has those defects that have already been found by a user.

> 4. Code that depends on implementation dependent details. For example, one
>    of our large customers had a heck of a time tracking down a "bug" which
>    turned out to be a case where a packed array of length (1 .. 32) of
>    booleans was mapped to an external hardware address. The Verdix compiler,
>    perfectly reasonably, loaded the entire 32-bit word to test one bit. GNAT
>    perfectly reasonably, loaded only the byte containing the bit to be tested.
>    Normally these two approaches would be identical, but their hardware could
>    not handle byte addressing for this address. We "fixed" GNAT to do a word
>    access in this case, but it was not of course a bug in GNAT.

Whose bug it is in cases like this depends on whether it was a documented
or undocumented hardware restriction.  I have run into some nasty problems
caused by failure to follow documented hardware restrictions, even by folk
who were involved in writing those restrictions !  Even for hardware
manufacturers who embrace GNAT as the solution to their Ada 95 "problem"
there may be a cultural bias against full disclosure or simply a lack
of internal documents laying out such problems.

> Ada programs are typically highly portable, but it is important not to
> oversell this feature. I once heard the project director for the IBM
> air traffic control system say that Ada 95 must guarantee that their
> application move without changing a single line of code. The mere fact
> that someone could state this obviously unrealistic requirement worried
> me at the time, since it seems to me that anyone working with large
> Ada applications should have a more realistic view.

At the "project director" level, I think this constitutes a "bargaining
position".  If this was a serious bidding situation, one might be quite
safe accepting such a restriction with a waiver count corresponding to
the amount of bad Ada 83 code found in the software. (I say that hoping
that "bad" is not one of those reserved terms like illegal, erroneous,
undefined, etc. :-).

Larry Kilgallen