Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!unmvax!deimos.cis.ksu.edu!atanasoff!hascall
From: hascall@atanasoff.cs.iastate.edu (John Hascall)
Newsgroups: comp.arch
Subject: Re: 80486 vs. 68040 code size
Message-ID: <1083@atanasoff.cs.iastate.edu>
Date: 10 May 89 21:47:52 GMT
References: <3150@tank.uchicago.edu> <1921@se-sd.sandiego.ncr.com>
Reply-To: hascall@atanasoff.cs.iastate.edu (John Hascall)
Distribution: eunet,world
Organization: Iowa State Univ. Computation Center
Lines: 27

In article <1921@se-sd.sandiego.ncr.com> lord@se-sd.sandiego.NCR.COM (Dave Lord(SSP)) writes:
>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
 
>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 ...};
			     &&  (I presume)
  
>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).
 
     This can already break on many machines--say, for example, if the
     last byte of the array just happens to fall on the last byte of
     a page (and the next page is no-access).

     Since the C operator && guarantees short-circuiting I don't see any
     reason to use such sloppy code (just re-order the expressions).

     John Hascall
     ISU Comp Center