In message <mtu8z938svv.fsf@kinki-sharyo.mit.edu>, "Nathan J. Williams" writes:
>seebs@plethora.net (Peter Seebach) writes:
>> I don't think I've had a bounds overflow problem in C in ten years.  It's
>> just not that hard to avoid, *if* you understand what you're doing.

>1) I don't believe you. You are not infallible.

No, I'm not.  However, so far as I can tell, my failures are generally much
cooler than bounds overflows.  Bounds overflows are easy; if you allocate
static buffers, you check things.

You're welcome to go through my code and try to find bounds overflows.  The
only programs I think are likely to have them are my "userfights" program
and my "grain game" program - both of which are '92 or earlier.  :)  I'll even
put a $20 bounty on the first bounds overflow in my "maintained" code.

http://www.plethora.net/~seebs/c/pkg-0.8.14.tar.gz

I'll be generous; anything but "grain.c" or "uf.c".  If I were you, I'd start
on the dysfunctional minesweeper; I think I crashed it once.  If you want a
typical target, look at the string library; it does self-allocating strings,
which do their own bounds checking in a half-dozen different ways.

>2) Even if I did, there are always worse programmers.

True.

>3) This should not be an issue of trust or faith. It should be an
>   issue of enforced protection.

While I like the idea of a language trying to guarantee integrity, in the
end, you still need to do your own bounds checking; the alternative is still
always a problem, and you always need to remember that, some day, the compiler
will screw up.

So, this doesn't actually make the code any easier; it just means that you'll
have more core dumps and fewer exploits, in theory.  (I don't know what
happens in practice, yet.)

-s