From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f849b,b8d52151b7b306d2 X-Google-Attributes: gidf849b,public X-Google-Thread: 103376,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-23 14:11:57 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!news-out.visi.com!petbe.visi.com!in.100proofnews.com!tdsnet-transit!newspeer.tds.net!news.binc.net!kilgallen From: Kilgallen@SpamCop.net (Larry Kilgallen) Newsgroups: comp.arch.embedded,comp.lang.ada Subject: Re: Certified C compilers for safety-critical embedded systems Date: 23 Dec 2003 16:11:51 -0600 Organization: LJK Software Message-ID: References: <3fe00b82.90228601@News.CIS.DFN.DE> <3FE026A8.3CD6A3A@yahoo.com> <3bf1uvg2ntadvahfud2rg6ujk24sora6gr@4ax.com> <2u3auvogde8ktotlaq0ldiaska3g416gus@4ax.com> <20619edc.0312221020.3fd1b4ee@posting.google.com> <20619edc.0312222106.3b369547@posting.google.com> NNTP-Posting-Host: eisner.encompasserve.org X-Trace: grandcanyon.binc.net 1072217474 14375 192.135.80.34 (23 Dec 2003 22:11:14 GMT) X-Complaints-To: abuse@binc.net NNTP-Posting-Date: Tue, 23 Dec 2003 22:11:14 +0000 (UTC) Xref: archiver1.google.com comp.arch.embedded:6037 comp.lang.ada:3771 Date: 2003-12-23T16:11:51-06:00 List-Id: In article , Alan Balmer writes: > On 23 Dec 2003 14:33:11 -0600, Kilgallen@SpamCop.net (Larry Kilgallen) > wrote: > >>> Since a large part of my work is maintenance of legacy systems, I'll >>> readily agree that the error rate I encounter is horrible. I'll also >>> claim that error rates of programs I've completely reworked are very >>> low. >> >>One of the big flaws in replacing a software system outright is to >>ignore the fact that requirement capture has been inadequate. > > I'm not quite sure what you mean. In maintenance work, the only reason > to modify a program is because it doesn't, in some respect, meet > requirements, either the original requirements or new requirements > which have evolved. Requirements are rarely static during initial > development, let alone a few years down the road :-) For years the program has met some requirements that are "hidden". Users depended upon certain features but they were never called out as features in the documentation - they were useful interactions between different documented features. A good example is the VMS Mail program, which someone decided to rewrite from Bliss into C, most likely because they favored C. Now, ten years later, they are just getting rid of the MAIL/OLD command that invoked the previous Bliss implementation. They had to carry it that long because of all the undocumented features missing from the Bliss version. > When I say "completely reworked", I don't mean to imply that I rewrite > programs from scratch. I make them ANSI compliant and warning free, > eliminate unused elements, eliminate globals as far as possible, > eliminate unsafe (often erroneous) practices and code, restructure > and recode to make the code more maintainable, and where possible > replace internal functions with standard C functions or functions from > our proven in-house libraries. Ok, that is different. Larry Kilgallen Who subsequently rewrote a Bliss program into Ada, knowing the lesson of VMS Mail, because the original Bliss design was incompatible with new requirements. That rewrite is just now starting to hit the streets. Wish it luck :-)