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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 6 Apr 93 21:27:42 GMT From: howland.reston.ans.net!zaphod.mps.ohio-state.edu!uwm.edu!lll-winken.llnl. gov!taurus.cs.nps.navy.mil!shimeall@gatech.edu (timothy shimeall) Subject: Re: C to ADA translators. Message-ID: List-Id: In article groleau@e7sa.crd.ge.com (Wes Groleau X7574) writes: >1. I found some free code in C that meets 95% of my requirements. I want >to translate to Ada so that I have some hope of meeting the other 5% by my >deadline. (I was able to make a nice low bid because I knew about this code.) You miss the point of the objection. First, you are assuming that a mechanical translation from C to Ada would produce a reliable program written in Ada from a reliable program written in C. This is debatable, given the ambiguity of several of the common idioms used in C code. For example, it is quite possible that the correct interpretation of the c declaration: void dosomething(a) int ***a; would be the Ada declaration: procedure dosomething(a:in out int_ptr_array) is ... (in other words, the first * in the C declaration indicates an in out parameter, the second * indicates the parameter is an array, and the third * indicates the array holds pointers.) but how would you design a software system to disambiguate this from the OTHER possible interpretations of int ***a? To get around this (and many other, similar) problem, you need a complete review of the generated Ada code by someone who thoroughly understands the C code being translated, the rules used to translate it, and the proper Ada translations -- I submit (from experience in trying mechanical translations) that this review will be more expensive, and slower, than reverse-engineering the "free code" and rewriting it from scratch. Second, you assume that your customer wanted the code in Ada because of some mystical belief in Ada. This is probably false. He wanted it in Ada because he didn't want to have to support multiple language compilers and multiple language training for the duration of the system lifespan. In short -- He wanted the system in Ada to simplify maintenance. A mechanically-translated piece of software is likely to be unmaintainable, unless you do a LOT of reworking and commentary. So you deliver an unmaintainable system and your company loses reputation. >2. My (non-programmer) systems engineers (in our company, those are the guys >that write the specs and can't distinguish between requirements and >implementation) want me to incorporate the 16-Kilbyte FORTRAN simulation they >used to develop the spec into the test support software. Management is not >sympathetic to my desire to re-design something that "already works" Point out to the systems engineers that you cannot guarantee that the mechanically-translated simulation will produce the results the FORTRAN simulation produced, whereas a redesigned simulation might (if done properly) be so guaranteed. If they want you to incorporate the unverified simulation anyway, go ahead and do it, but ask for the instruction in writing... If you want to go with some sort of translation, look into DRACO or similar efforts that abstract the DESIGN from an implementation in the source language and then refine the design into the target language. But be warned, such tools are a) difficult to find and b) require effort to use. Tim P.S. Note, while I'm writing from a Navy cite, I'm not a spokesperson for the Navy, nor should any of the above statements be considered policy statements of any organization.