Lit. Buffer overruns 1703
snip If I gave the impression that I thought that was a reasonable general approach to fixing buffer overruns -- not at all!! In many circumstances (I would say "most" but could be wrong), that...
As I said in another reply I just posted, I think we must mean different things by "buffer overrun" (or overflow). I mean the situation in which a program (typically an application user non-OS program) tries to put, say, 100 integers into an array that was only declared-allocated to hold 10. Of course this is usually going to lead to bad results, but it can be avoided by writing the program differently.
What I understand you to be talking about is some *other* enbreasty (another application program, the OS, something) messing with the running program's memory. That's what my "yipes" refers to, and I was thinking that it would be difficult if not impossible for a program to defend itself from that kind of tampering -- although a followup from one of the sci.crypt seemed to indicate that there *are* things one can do.
Oh, *hardware* errors .... Yeah. Okay, sorry, I wasn't thinking about those. I think we've had some variant of this conversation before. Maybe I'll get it eventually.
And paranoia in a developer of OS-level code is probably a fine trait. Indeed, is it really paranoia when "they" (hardware that might fail, users that *will* mess up) really *are* out to get you?
-- B. L. Mbuttingill ObDisclaimer: I don't speak for my employers; they return the favor.
Alt Folklore Computers from Newsgroups