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=-0.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM, REPLYTO_WITHOUT_TO_CC autolearn=no 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 13:46:32 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!69.26.224.5!not-for-mail From: Alan Balmer Newsgroups: comp.arch.embedded,comp.lang.ada Subject: Re: Certified C compilers for safety-critical embedded systems Date: Tue, 23 Dec 2003 14:46:30 -0700 Organization: Balmer Consulting 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> Reply-To: albalmer@spamcop.net NNTP-Posting-Host: 69.26.224.5 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1072215990 11659658 69.26.224.5 ([162642]) Cancel-Lock: sha1:Fk6zZ/BanWrSX+FsQSFWrcJI7JY= X-Newsreader: Forte Agent 1.93/32.576 English (American) X-NFilter: 1.2.0 Xref: archiver1.google.com comp.arch.embedded:6033 comp.lang.ada:3768 Date: 2003-12-23T14:46:30-07:00 List-Id: 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 :-) 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. At that point I can stand to read it, and the real work begins . After this, usually there is considerable refactoring and often some replacement of algorithms. Some testing is done during the process. A code review follows, corrections are made if needed, and more formal unit testing is done before turning the product over to QA. Typically, during this process, I'll identify a dozen or more bugs in an average thousand-line program. Some of them will be recognized by our support people - "Gee, it's been doing that every couple of months, but we couldn't reproduce it" , or more often "It's always done this, but we have a workaround." That last, incidentally, is a real problem for us. Our support people are good, and often come up with workarounds to problems they never tell us about. They enjoy being heroes to the customer, and can't be persuaded that they'll never run out of work ;-) -- Al Balmer Balmer Consulting removebalmerconsultingthis@att.net