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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e881d094f2c5abdf,start X-Google-Attributes: gid103376,public From: "Condic, Marin D." Subject: Re: Is there a language that Dijkstra liked? (was: Re: Software l andmines (loops)) Date: 1998/10/30 Message-ID: #1/1 X-Deja-AN: 406679552 Sender: Ada programming language Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Content-Type: text/plain MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-10-30T00:00:00+00:00 List-Id: dennison@TELEPATH.COM writes: > >The part that I find tres' cool is that the run-time checks tend to make a >buggy program bomb very close to the true source of the problem. Without it, >bugs surface randomly. On a large networked system It can take weeks just to >find the source of such a "random" bug. > >I've seen one instance where a C array bounds indexing bug caused garbage to >get passed through 2 intermediate machines, processed, and sent to a third >which blew up trying to dereference the pointer it got by using the resultant >garbage as another array index into an array of poiners. Two engineers were >flown into the customer site and put up in hotels for 2 weeks while they >tried to figure out what was going on. Of course if it were written in Ada, a >range check would have caused the program to bomb at the line where the >invalid index was first used. A decent compiler will then print a stack dump >with the error, routine, and line number. We could probably have fixed it >over the phone in less than a day. It only takes one bug like that to >completely erase any cost savings you thought you were getting by using that >cheap C compiler. > There are any number of such stories. I'd have to agree about discovering the error close to the source - especially in embedded systems where it is difficult/impossible to use symbolic debuggers, coverage analyzers or even embed a few trusty "Put_Line" calls to see what's going on. I have frequently been saved hundreds of debugging hours because of Ada's built-in run time exceptions. Most of the time, we run with the bulk of run time checks disabled because of speed issues, but when something serious is going wrong and nobody has a clue as to why the software/hardware is failing, one of the first steps to solving it is to recompile the code with checks enabled - possibly with some instrumentation like adding exception traps in suspect areas - and monitoring it from there. More often than not, you get an immediate indication of where the problem is occurring and can generate a fix right away. Compared to similar things I've had to do in C, it's clear that Ada's run time checks are a major advancement. Anybody who has debugged C code on an embedded system is likely to appreciate array bounds checks, etc. More times than I care to remember, I've spent late nights tracing runaway C code that's scrogging memory because an array index just keeps going and going.... MDC Marin D. Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 Ph: 561.796.8997 Fx: 561.796.4669 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- G.B. Shaw