Re: Is there a language that Dijkstra liked? (was: Re: Software l andmines (loops))

Re: Is there a language that Dijkstra liked? (was: Re: Software l andmines (loops))

[Condic, Marin D.]

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