🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.modula2
Article #2585

Re: Report on defect in M2 vs C (Was Modula-2, Modula-3, C or C++)

#2585
From: Viet-Trung Luu
Date: Thu, 05 Oct 1995 18:46
50 lines
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!vluu
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>

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