At 11:32 02/09/99 -0500, Alan King wrote:
>NO, the discussion was about masking the argument to make sure and at
>least stay in the table vs randomly hitting other code.  I was going FOR
>masking, at least I hit a timing value and come back, so it will be
>early or late.  If you don't mask, you don't know WHAT your code is
>doing..

ok, but i assume that if you have to mask the jumps (that is, if the mask
has any effect), you don't know either what your code is doing, because you
don't know why you get that index out of bounds. (usually one makes sure
that in =no= case one can think of the index gets out of bounds. so this
clearly is a case one =didn't= think of...)

if you correctly mask all table reads, and make sure that all possible
reads don't jump outside of the table and really get results only
=slightly= off, you might have a point. (which i guess is impossible,
because what hinders your device to give the result "3000 feet abouve
ground" when it's only 3 feet and the device is not working properly,
albeit not jumping out of the table because of the mask? usually masking a
value, especially the high bits, does not result in "slight" changes, it
results in pretty strong changes. there are of course exceptions, like
linearization tables which only add a small amount to a linear function.
but especially in these cases masking the index is particularily bound to
leave a bug in the linearization algorithm undetected, because the wrong
results are only slightly wrong. during testing i'd rather have it jump
into nowhere or stop at the mask than go on.)

so the point is: =if= your code gets into a table with an index out of
bounds, this is a serious bug and should get caught at design (or
debugging) time. and there the mask might not be very helpful, since your
code happily runs along, possibly without you realizing that there is a
problem. (it of course may be helpful, if you do something other than going
along when it hits the mask.)


>  I do not see how you expect your code to fall off the end of a table,
>but somehow magically still be running like you expect, and see
>something is wrong to do the beep or shut down and execute your fail
>safe.  You're arguing for having your code make hard errors, but making
>your case like you're still executing your code..

depending on the design, i assume that the probability for eg. a watchdog
to hit is bigger if you let the code jump out of the table. but in this
case (like life-support systems), i probably would say the mask is right in
order: but the device should probably better shut down safely (whatever
this means in this circumstance -- eg. it could mean "continue to work, but
let the user know that it's possibly not reliable anymore") than simply go
along with a masked (and therefore arbitrary) index if the index is out of
bounds.

this, again, unless you can make sure that in no case of an index out of
bounds getting masked (and therefore arbitrary) the result is in unsafe
regions. but this of course depends on a lot of details and is not
generally so.

ge