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.