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: f43e6,899fc98b2883af4a X-Google-Attributes: gidf43e6,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-16 10:30:30 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: mcq95@earthlink.net (Marc A. Criley) Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,comp.software-eng Subject: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers) Date: 16 May 2003 10:30:29 -0700 Organization: http://groups.google.com/ Message-ID: <254c16a.0305160930.40bb42f9@posting.google.com> References: <9fa75d42.0304230424.10612b1a@posting.google.com> <7507f79d.0305121629.5b8b7369@posting.google.com> <9fa75d42.0305130543.60381450@posting.google.com> <254c16a.0305140549.3a87281b@posting.google.com> <9fa75d42.0305141747.5680c577@posting.google.com> <1053027582.984315@master.nyc.kbcfp.com> <3ec4b5c5$1@news.wineasy.se> NNTP-Posting-Host: 12.158.183.115 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1053106230 27348 127.0.0.1 (16 May 2003 17:30:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 16 May 2003 17:30:30 GMT Xref: archiver1.google.com comp.lang.java.advocacy:63934 comp.object:63554 comp.lang.ada:37397 comp.software-eng:19238 Date: 2003-05-16T17:30:30+00:00 List-Id: "soft-eng" wrote in message news:9fa75d42.0305160453.29c0c4af@posting.google.com... > The point I have been trying to make is that Ada catches > a small extra subset of errors (and compared to modern C, C++ > or Java, the "extra" might be non-existent). Ada or not, > you should have a mechanism that catches those errors > before you ship out the jet engine. And it's that point you're trying to make that reflects a startling tunnel vision on your part. > With professional programmers, the "type errors" are > very few anyway (I estimated 2-3% of all errors, > so if a bug-list has 100 items on it, and if more than > 2-3 are type-safety issues, I would worry about > programmer quality.) Assuming an Ada-coded system where proper usage has been made of strong typing... I'm not positive what you mean by "type errors"--I see two potential interpretations that are relevant to Ada: 1) Type conflicts 2) Range errors The first, type conflicts, are fixed almost without thought by an Ada programmer, since the program won't compile until they're are. If I swap Lat and Lon in a procedure call, or mis-assign a "Plan_Number" value to an "Engagement_Number" variable, it's immediately caught and I fix it--I don't even bother to count that as a defect--so it never makes it onto a bug list--that's just a momentary "oops" on my part. What happens when you swap nLat and nLong in a function call? You get an object file, I get a compile error. When does it get noticed? When you run a test, when I look at the compiler's output. These little type conflicts are always caught and fixed, without the Ada programmer even thinking about it--these errors just never make it into the test regime, because they've been long since dealt with. Range errors get automatically detected at run-time in an Ada-coded system, where they can be as simple as an off-by-1 error, and who hasn't dealt with that one? What happens when your indexing is off by one? The program may crash, or it may not. It may corrupt neighboring data, or it may not. It may often exhibit erratic behavior, or it may do so intermittently. When my indexing is off by one an exception is raised and I immediately know there's a problem that I need to identify and fix. ------------------------------ But granting this low estimation of "type error" occurrence, that means many of the remaining errors would be designated as "logic errors", and it's been suggested that this is the type of the majority of errors (which I believe is true), and that neither Ada nor any other language is inherently capable of preventing logic errors--also true. So your assertion appears to be that 1) most software errors are logic errors, and 2) Ada's strong typing only helps prevent an uncommon type of error (type errors), therefore the effort required to work with or around Ada's strong typing adds no value to the detection and correction of the predominant type of error (logic). Okay then, so how _does_ one know they've got a logic error in their code? The error is going to manifest itself in one of three ways: 1) The program runs but the functionality isn't as desired. This may be obvious (it immediately exits), or not (a cumulative microsecond drift that becomes noticeable only after a couple days caused by a counter not getting reset). 2) The program crashes at some point. 3) The program runs but behaves erratically, and this behavior may be intermittent. In the third case, clearly Ada and strong typing would likely be of benefit here, since such erratic behavior may arise from "type errant" run-time behavior that was initiated by executing the wrong logic. Pretty much every time an unexpected exception occurs in an Ada-coded program, the cause is a logic error that causes the execution of code that is an inconsistent internal state (because that code wasn't supposed to be executed!). Stale data values may be referenced, garbage values may be in variables, and as soon as Ada does a range check on them, everything halts--and you can go track down the problem. In the second case, one has to determine what led to the crash: Was it an immediate crash at the point of error? E.g., trying to write through a null pointer? Or was the program getting messed up internally, but gave no indication and continued to run for awhile before the cascade of errors got so bad that it crashed? If the former, Ada's no better or worse than any other language in which that occurs, but if the latter, you've just got case #3 again, but where it does eventually terminate. In the first case, things like peer reviews and formal inspections have proven to be of measurable assistance. > So the tradeoff is, possibly a bug or two caught > at compile time rather than during testing, versus > using a very large language that was created by fiat. Again, you're not counting the errors that _never_ occur _because_ of strong typing. (And you've also been ignoring all mention of how the type information embedded within Ada software due to its strong type model also aids correctness and maintainability.) Because C/C++ doesn't flag type conflicts among values having the same base type (int or float) and also does implicit type coercion, you never see such conflicts when you're compiling your software, and by the time they manifest themselves--in test--they've become logic errors: "I meant to use Latitude rather than Longitude here." Marc A. Criley