Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: Is the Intel memory model safe from NO-ONE ?!?
Message-ID: <52504@sun.uucp>
Date: 9 May 88 18:47:53 GMT
References: <1806@obiwan.mips.COM> <2904@omepd> <353@cf-cm.UUCP> <2448@louie.udel.EDU>
Sender: news@sun.uucp
Lines: 30

>   i guess if you assume all these things are interactive, that is ok. 
> What about all the daemons that run in background and screw up? 

If the problem is caused by e.g. a control file being bad, or some network
input being bad, or something such as that, subscript-range checking should not
*need* to be present; again, the program should explicitly check for bad input
and report the error somehow.

> I would like something, anything, better than a core file.

I would like something better than a stack trace (the core file may be one way
to *get* this kind of information, BTW, especially if the
subscript-range-checking code causes a core dump when it detects an
out-of-range subscript).  I would like to be told that I screwed up a
configuration file, or that host "xyzzy" sent me a bad packet, or something
like that.

I don't deny that subscript range checking can be useful for detecting bugs.  I
would prefer, if this is feasible, a compiler that didn't let people put those
bugs into the code in the first place; e.g., one that would warn you that a
given array reference could have an index outside the bounds of the array.  One
way to make sure it doesn't have an index outside the bounds of the array is to
put in explicit checking code which prints a useful message, sends back an
error packet, or whatever if the array is invalid.

>   In thinking about it, i guess i am arguing for more than two 
> address spaces per program. Right now we have code and data. 
> Is there so much wrong with having more than one data space?

No, I never said there was.  However, segmentation isn't the *only* way to get
subscript range checking.  It may be that other ways are more cost-effective.