Re: Porting Ada83 to Ada95 compiler/VxWorks

Re: Porting Ada83 to Ada95 compiler/VxWorks

[Tucker Taft]

"Robert Kershaw, KG4ASZ" wrote:
> 
> I need to port about 12K SLOC of code in Ada83 to Ada95 running under
> VxWorks. Does anyone know of a good resource describing the
> differences from Ada83 to Ada95?

The short answer is that Ada 83 is a subset of Ada 95.
The long answer about compatibility (and it is probably much
more detail than most people need to know) can be found at:

    http://www.adaic.org/docs/compat-guide/compat-guide6-0.txt
 
> Any advice?

Try compiling the code.  The few incompatibilities that exist
are almost always caught at compile-time, and many compilers
even give you a hint as to how to fix the problem.  Here are
the few "significant" incompatibilities:

   1) type Character now has 256 enumeration literals
       (this was actually permitted even before Ada 95 arrived)
   2) library packages must *not* have a body unless the
       body contains the completion for some declaration in the spec,
       or the spec contains a "pragma Elaborate_Body;"  (i.e. there
       is no such thing as an "optional" library package body in Ada 95)
   3) you need to decide in a generic whether a formal private type
       should or should not allow the actual type to be "indefinite."
       If the answer is yes, then you need to add a "(<>)" to the
       formal private type declaration.

In general, the bigger porting problems are usually due to 
code that was originally target-dependent or compiler-dependent.

> 
> Thanks,
> RSK

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Porting Ada83 to Ada95 compiler/VxWorks

[Robert Dewar]

In article <382B4F79.F8B31A68@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
>    1) type Character now has 256 enumeration literals
>    2) library packages must *not* have a body ...
>    3) you need to decide in a generic ...


In our experience, much more important is

>    4) the meaning of 'Size has changed radically

In Ada 83, the meaning of 'Size was not completely well
specified but in practice, was very uniformly implemented.
In particular, sizes of subtypes generally matched sizes
of the base types, so for example, Natural'Size was the
same as Integer'Size, typically 32. As far as I know, the
only Ada 83 compiler implementing something different was
the very rarely used Intermetrics compiler for the IBM
mainframe, but I am happy to be corrected on this if someone
knows some other compiler ...

In Ada 95, an attempt was made to define 'Size more precisely
(a good thing), but the choice made, though formally consistent
with the lack of specification in the Ada 83 RM, was to insist
that Natural'Size be 31 (a very bad thing). This actually
violates one of the requirements in the Ada 95 requirements not
to introduce incompatibilities with existing practice, but
unfortunately this did not get fixed in the revision process.

What this means is that a declaration like

  type x is record
    A : Natural;
    B : Character;
  end record;

  for x use record
    A at 0 range 0 .. Natural'Size - 1;
    B at 0 range 0 .. Natural'Size .. Natural'Size + 7;
  end record;

has radically different semantics in typical Ada 83 compilers
and Ada 95.

Yes, from a formal point of view this is indeed in Tuck's
category of implementation dependent code, but that is really
a formalism. In practice this was a definitely incompatible
mistake in the Ada 95 design, and is something to watch out
for. Similarly suprising is:

   type x is array (1 .. 10) of Natural;
   pragma Pack (x);

In an Ada 83 compiler, this would never pack to 31 bits, since
Natural'Size is 32 bits, but in Ada 95 compilers it may pack to
31 bits causing porting problems.

This has been one of the biggest porting headaches that I would
really put in the category of incompatible changes, rather than
ill-advised or ill-understood implementation dependent code
(indeed the record rep clause above is clearly a concientious
attempt to AVOID being implementation dependent).



Sent via Deja.com http://www.deja.com/
Before you buy.