Re: XX(PL/I) to Ada translator/lessons learned

Re: XX(PL/I) to Ada translator/lessons learned

[Pa ul Stachour]

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

Re: XX(PL/I) to Ada translator/lessons learned

[Michael Feldman]

In article <1993May26.070218.5567@sctc.com> stachour@sctc.com (Paul Stachour) w
rites:

[other good stuff deleted]
>
>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.
>
I KNEW there was a good reason to hate Ada, but I couldn't put my
finger on it till now. It's all that DAMN run-time bounds checking!
Wouldn't you rather not have known about this? After all, the crash
would probably have occurred on someone else's watch... :-) :-) :-)

(Oh, what the hell. Just use pragma SUPPRESS...)

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"The most important thing is to be sincere, 
and once you've learned how to fake that, you've got it made." 
-- old show-business adage
------------------------------------------------------------------------

Re: XX(PL/I) to Ada translator/lessons learned

[dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!ux1.cso.uiuc.edu!moe.ksu.ksu.edu!kuhub.cc.ukans.edu!hawk!billk]

In article <1993May26.070218.5567@sctc.com> stachour@sctc.com (Paul Stachour) 
  writes:
: 
: 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.
: 
PL/I also does a runtime check of array bounds.  If you have done an
accurate translation the behavior should be the same using either language.

-- 
--Bill Kinnersley
  billk@hawk.cs.ukans.edu
226 Transfer complete.