[3485] in cryptography@c2.net mail archive
Re: Medium-term real fix for buffer overruns
daemon@ATHENA.MIT.EDU (Andreas Bogk)
Thu Oct 15 18:22:14 1998
Date: Thu, 15 Oct 1998 16:00:11 +0200
From: Andreas Bogk <ich@andreas.org>
To: Lenny Foner <foner@media.mit.edu>, gnu@toad.com, karn@qualcomm.com,
decius@ninja.techwood.org, smb@research.att.com,
reinhold@world.std.com
Cc: cryptography@c2.net
In-Reply-To: <9810150328.AA07938@out-of-band.media.mit.edu>; from Lenny Foner on Wed, Oct 14, 1998 at 11:28:22PM -0400
On Wed, Oct 14, 1998 at 11:28:22PM -0400, Lenny Foner wrote:
> I must admit, I'm enjoying a sort of grim satisfaction in this
> exchange, mostly because I have spent the better part of a decade
> trying to avoid C whenever possible. Why? Because I've used---and
I must admit, me too. I'm co-maintainer of Gwydion Dylan[0], a free
implementation of the language invented by Apple. The experience shows
that many of the prejudices against certain features such as automatic
memory management and bounds checking that tend to make people use
C are simply not true anymore today. Especially the performance
issues are pretty much solved.
> Things like the lispm (and various capability-machine architectures)
> also showed that you can do a lot of the runtime stuff in hardware,
> with little or -no- cost in performance. Even a lot of GC could
> happen very fast, given an extra 5% in CPU transistor count, which is
> about what you'd add to implement, say, virtual memory. Perhaps in 20
In fact, using the VM available today to detect changes in the pointer
structure gives you very light-weight GC. Of course, a VM that is
object-based instead of page-based, and that knows the difference between
pointer and data would help, but it's hard to say if it's worth the
overhead.
> years we'll look at hardware bounds protection as just as necessary as
> VM is now to a "real" computer---or perhaps the New Jersey approach
> will continue to triumph. [I should point out that applicability of
I'm not sure about this. You pay the cost of bounds protection regardless
of wheter you see it explicitly in the code (as it is with RISC today)
or you do it hidden in the instruction, as you suggest. The RISC approach
allows the compiler to move out or optimize away the bounds check if
it can prove it to be unneccessary. This also means that the bounds check
that a language generated automatically is by no means slower than the
one you have to do manually to prevent buffer overflows in C.
And other than Steve, I wouldn't just blame lousy code quality for what
we see with C today. Every programmer has a limited set of problems
that he can cope with at the same time. If he has to care about buffer
overflows explicitly, he loses the time and capacity to cope with the
original problem he wanted to solve with his program in the first place.
Andreas
[0] Dynamic, object-oriented, with automatic memory management, and
designed with performance in mind. If you think that perl is
nice, although slow, you might like Dylan.
--
Gwydion Dylan Development -> http://www.randomhacks.com/dylan
"We're fully buzzword-compliant."
