Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-sdd!ncr-sd!se-sd!lord
From: lord@se-sd.sandiego.ncr.com (Dave Lord)
Newsgroups: comp.arch
Subject: Re: 80486 vs. 68040 code size
Message-ID: <1921@se-sd.sandiego.ncr.com>
Date: 10 May 89 17:30:31 GMT
References: <3150@tank.uchicago.edu>
Reply-To: lord@se-sd.sandiego.NCR.COM (Dave Lord(SSP))
Distribution: eunet,world
Organization: NCR Corp. Systems Engineering, San Diego
Lines: 26

In article <3150@tank.uchicago.edu> phd_ivo@gsbacd.uchicago.edu writes:

>byte? This way, one can put a single No-ACCESS byte between datastructures at
>link/load time, which should detect out of pointer ranges much more quickly
>than the wait-and-see in use in our systems. (At least I have spent days of my
>life searching where wild pointers.) It would also seem that this concept would
>go quite well with object-oriented languages, which try to but never can check
>if non-member functions access objects.

With my Computer Scientist hat on I think this is a great idea, but with
my 'can we sell this system' hat on I see a potential problem:

How much "C" code have you seen that does something like this:

	while (a[index] != 0 and index++ <= A_BOUNDS){ ... whatever ...};

The above is lousy code (it could also be done with pointers) but the
problem is that it almost always works OK. How many people will scream
because they have to clean up their programs to get them to run on
your system. Will there be problems porting important applications?

OK, if you don't see it, we are overrunning the end of the array. The
above case is easy to fix, but other cases might not be. And before
you flame me, I assure you, I wouldn't code that way (Usually).

Dave Lord