From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=3.0 tests=BAYES_50 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 26 May 93 07:02:18 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!darwin.sura.
net!news-feed-1.peachnet.edu!umn.edu!sctc.com!stachour@ucbvax.Berkeley.EDU  (Pa
ul Stachour)
Subject: Re: XX(PL/I)  to Ada translator/lessons learned
Message-ID: <1993May26.070218.5567@sctc.com>
List-Id: <comp.lang.ada>

tsorense@perky.dasd.honeywell.com (Todd A Sorensen) writes:

>A warning to those who are contemplating such a job as translation of code
>from one language to another:

>We translated Intel PLM (c) to Ada,  while we got about a 90% yield
>syntactically,  the functional yield was below 50%.  (it was fairly easy to
>get to compile, but it didn't work)
------------------------------------------------------------
Several years ago I was given a job to do.  I didn't know anything
about the subject.  I did a short literature search. It turned up
a paper by Morrie Glasser, and a reference to the PL/I Code on
Multics that did the job.  I talked to some people on the phone,
and got a copy of the copy.  I was told that the code had ran for
more than 10 years, and never had a fault, nor any reported failure.

Well, I was working in C, so I translated the code to C.
Like in any translation, you have problems when the language
you are translating into doesn't support some things that the
language you are trasnlating from does.  Anyhow, I did a realitvely
straigtforward translation.  The code looked (and was) ugly; caused
by the fact that the PL/I used internal procedures; C doesn't have
that, and the shared variables into the internal procedures
made it quie wierd when I got done.

Anyhow, it compiled without error.  Been ruuning two yers now.
Still looks ugly; not maintainable, but it doesn't need to be.
It works. Gets the right answers. Never faults.

Well, not quite true.  As an experiment, I translated the same
PL/I code into Ada.  Yes, it was still a little wierd.  Not as
bad as the C, but still weird.  So I compiled the code (no error
messages), and ran a few test-cases.  Bamb! Took an exception
(arressing outside the bounds of an array) on the first test.

Analysis time.  Yep, the code is "coincidentally correct".
The element of the array that's out-of-bounds is combined
with other data in such a way that it never affects the 
results of the computation.

But, it is a lurking boundary condition just waiting to happen.
Some day, with some compiler, it'll lay out the data-structures
to put that "wrong element" in the next page of memory, which
my program doesn't own.  And then it won't be a benign error;
it'll be a real failure.

Moral of the Story:
  You may find more than you want when you take a "working"
program and move it to another environment.

Cheers, ..Paul

-- 
Paul Stachour              SCC, 2675 Long Lake Road
stachour@sctc.com          Roseville, MN  55113
                             [1]-(612) 628-2782