Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!ucbvax!pasteur!dog.ee.lbl.gov!george.lbl.gov!antony
From: antony@george.lbl.gov (Antony A. Courtney)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Message-ID: <6701@dog.ee.lbl.gov>
Date: 28 Aug 90 23:02:55 GMT
References: <1990Aug18.210132.25203@sco.COM> <2434@crdos1.crd.ge.COM> <6797.26d6edce@vax1.tcd.ie>
Sender: usenet@dog.ee.lbl.gov
Organization: Lawrence Berkeley Laboratories
Lines: 62
X-Local-Date: Tue, 28 Aug 90 16:02:55 PDT

In article <6797.26d6edce@vax1.tcd.ie> rwallace@vax1.tcd.ie writes:
>In article <2434@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:
>
>However automatically crasing the computer is NOT acceptable behaviour: I'd
>much rather do without the parity checking. Consider: suppose a parity error
>occurs on a 640K machine. The error is probably in either an unused area of
>memory (e.g. at the DOS prompt) or in a section of code that isn't going to be
>executed on this session with the program (e.g. error handling code).
> ...
>OK take the very unlikely case that
>it is in your data. For me that means in the source for a program I'm writing.
>This is no problem, I can just fix the one trashed character when the compiler
>barfs on the code. Much better than having the machine crash and lose several
>minutes' work.

Well, since you seem to be using the example of a compiler environment, I
notice you like to claim that the error will be "easy to catch" regardless of
where it occured.  

People have already pointed out loads of examples where this can cause
problems, but seemed to have skipped the obvious one:

Stray pointer problems.  Suppose it DOES corrupt your data for your compiler.
It could change the address of some pointer to god-knows-where.  Worse yet, it
might only change one of the more low-order bits, so that it only causes rare,
spurious problems for you.  (i.e. it still writes into data space, just into
the WRONG chunk of data space).  Worse YET, suppose the error occurs not in
just the execution or test phase, but in the actual COMPILE phase, so that
the address of some static pointer gets corrupted BEFORE the new binary gets
written out to disk.  That would be loads of fun to try and track down! :-)

Stray pointer problems are hard enough to track when __I__ am at fault, I
don't want to even THINK what it would be like to try and find them when the
hardware is flakey and doesn't tell me about it! :-)

Obviously written by someone who hasn't had to do enough debugging....

>The point is that ignoring a parity error is a pretty safe thing to do; there's
>very little chance of getting a misleading answer.

main()
{
	static int g[4]={1,2,3,4};
	printf("%d %d %d %d\n",g[0],g[1],g[2],g[3]);
}

output:

segmentation fault(core dumped)

I dunno about you, but I wouldn't exactly call this easy to catch...

>Russell Wallace, Trinity College, Dublin
>rwallace@vax1.tcd.ie

		~antony

--
*******************************************************************************
Antony A. Courtney                                        antony@george.lbl.gov
Advanced Development Group                           ucbvax!csam.lbl.gov!antony
Lawrence Berkeley Laboratory                                     (415) 486-6692