In message <mtubsdz8t43.fsf@kinki-sharyo.mit.edu>, Nathan J. Williams writes:

>
>Yes, bounds checking comes with a price. However:
>
>1) We have thirty years of compiler technology that can optimize out a
>   large fraction of expensive bounds checks.
>
>2) Isn't it worth paying a price for safety? That is the point of this
>   thread, to me; SSH is an application that should be optimized for
>   safety over speed.
>
>3) The low-level things that C allows and that bounds-checking
>   prohibits are almost always bad ideas, unless - and often not even
>   then - you're pounding the metal in the low levels of the
>   kernel. SSH is not doing that.
>

Bingo.  Here's what Tony Hoare said in 1981:

	The first principle was security...  A consequence of this principle
	is that every occurrence of every subscript of every subscripted
	variable was on every occasion checked at run time  I note with
	fear and horror that even in 1980, language designers and users
	have not learned this lesson.

Check out his Turing Award lecture -- CACM August 1981, I believe.

No, bounds checking isn't the fix to all of our security problems.
But about half of all new holes are due to buffer overflows.  Any time
I can solve half my problems that "easily", I'll take it, and then worry
about the others.

Speed?  I'll quote myself:  "How important is it to do the wrong thing
quickly?"

And yes, C is a major part of the issue, and C++ -- if used *correctly* --
will be a significant help without costing much in performance.  The
problem isn't just strcpy, it's also sprintf and a host of others.  And
the practice of using null-terminated strings instead of storing a
length means that even a good optimizing compiler can't do a good job
on string copies, whether explicit or via strcpy.

Btw -- a bounds-checking version of gcc does exist.  The catch is that
pointers are now larger than ints, which hurts other code.  It doesn't
hurt *conformant* code -- but being a multiplatform OS, NetBSD has a lot
of experience with programs that should port cleanly and don't.