Article View: comp.lang.modula2
Article #2585Re: Report on defect in M2 vs C (Was Modula-2, Modula-3, C or C++)
From: Viet-Trung Luu
Date: Thu, 05 Oct 1995 18:46
Date: Thu, 05 Oct 1995 18:46
50 lines
3356 bytes
3356 bytes
On 4 Oct 1995, Theodore Dennison wrote: > No, it had nothing to do with the OS. An "off by 1" array looping error > fetched garbage from elsewhere in the program. The program took this > garbage, sent it over the network to another machine, which read it in, > formatted it in another data structure, and sent it to a third machine. > The third machine later went to this item in the data structure, and > tried to use this "garbage" value as an array index. That fetched a > NEW garbage value, which was fed into a hardware device on a VME > backplane. The hardware device couln't handle this garbage value, and > locked up the entire backplane (including machine 3). Uhmmm... maybe it wasn't the fault of the OS... on the other hand, I have a few questions: Why didn't the software on the other machines check that the valid data (corruption can happen when you transmit things over a network)? For that matter, why didn't the device driver for the hardware check the data? > There is NO OS that would prevent this from happening. There is no > networking tool that would prevent this from happening (how would > they know the value is "garbage"?) A strongly-typed language would > have prevented this from happening. Don't you think that device drivers (which we usually consider to be part of the OS) should check the data that they're given? > Using C: > Symptom : Machine 3 locks up. > > Actual Bug : C code on Machine 1 has "off by one" error. > > Using Ada: > Symptom : Code on machine 1 core dumps, with PC pointing to line of code > where error is. While I agree that C isn't great in the way of "safety", I have a few objections to this argument of yours. The problem was evidently a programming error. However, even technically valid code can generate garbage -- and that would be a programming error also. Although C makes programming errors harder to detect and also more dangerous, it is not entirely responsible for the crash of the network. In general, I'd have to say that it was the fault of the device driver which didn't check the data that it was given. Similar situations occur in other circumstances. For example, the 'Doze and Mac APIs don't check the data that they're given very carefully. Therefore, application programs are often able to crash the system. Is it acceptable that it's possible to crash the system in this way? I have to say "no". - Trung
Technical Details
Message-ID:
<Pine.ULT.3.91.951005143816.2986A-100000@mobius04.math.uwaterloo.ca>Path:
arc1-ca.pugleaf.net!mobius04.math.uwaterloo.ca!vluuReferences:
<438nkr$bd@classic.eng.octel.com> <nelsoni.812298479@rintintin.Colorado.EDU> <44epau$qof@saba.info.ucla.edu> <44hcri$rsm@theopolis.orl.mmc.com> <44rv1u$dfk@apollo.ekfido.kodak.com> <44uccq$lkd@theopolis.orl.mmc.com>Show Full Headers
Complete Article Headers
Newsgroups: comp.lang.modula2,comp.lang.modula3,comp.lang.c,comp.lang.c++,comp.lang.ada Path: arc1-ca.pugleaf.net!mobius04.math.uwaterloo.ca!vluu From: Viet-Trung Luu <vluu@mobius04.math.uwaterloo.ca> Subject: Re: Report on defect in M2 vs C (Was Modula-2, Modula-3, C or C++) Sender: news@undergrad.math.uwaterloo.ca (news spool owner) Message-ID: <Pine.ULT.3.91.951005143816.2986A-100000@mobius04.math.uwaterloo.ca> In-Reply-To: <44uccq$lkd@theopolis.orl.mmc.com> Date: Thu, 5 Oct 1995 18:46:38 GMT Content-Type: TEXT/PLAIN; charset=US-ASCII References: <438nkr$bd@classic.eng.octel.com> <nelsoni.812298479@rintintin.Colorado.EDU> <44epau$qof@saba.info.ucla.edu> <44hcri$rsm@theopolis.orl.mmc.com> <44rv1u$dfk@apollo.ekfido.kodak.com> <44uccq$lkd@theopolis.orl.mmc.com> Nntp-Posting-Host: mobius04.math.uwaterloo.ca Mime-Version: 1.0 Organization: University of Waterloo