(I might be being overly nitpicky.) > Well, if it internally uses a lookup table and doesn't do bounds checking, then it can fail this way, and that failure wi

(I might be being overly nitpicky.) > Well, if it internally uses a lookup table and doesn't do bounds checking, then it can fail this way, and that failure will propagate to the caller. We're talking UB here, AFAICT. So it might do literally anything, including propagating to the caller. Or not. Or doing something entirely different, like returning true (or false)... or deleting your files. One wishes that out-of-bounds access would guarantee a SIGSEGV, but here we are... > Bad pointer access isn't fundamentally different from doing a bounds check and throwing an exception. Performance is the difference. If you're doing bounds checks for every access you're going to be slower than a compiler which can prove (for a loop, say) that no OOB access can possibly occur during said loop and just remove the bounds checks. > Either of them will tank the process if not handled up the stack. Again, not true -- an exception has defined behavior, a stray pointer doesn't. (It could, conceivably, but it fundamentally doesn't in C.)