Quoting Greg A. Woods (woods@weird.com):
> > My question stands:  What is SO WRONG with C that it should, as you have
> > put it, "be buried in an unmarked grave at midnight"?  I seek enlightenment!
> 
> some hints here, especially in the first paper referenced:
> 
> 	<URL:http://www.cs.cornell.edu/projects/cyclone/>

The problem with C is the number of possible ''holes'' there are. While
experienced programmers can avoid opening up a buffer overflow etc it
is, even for those experienced programmers, hard to do all the time. The
question then arises: Where should these problems be addressed?

OpenBSD attacks the problem by making the compiler reorder the stack
layout (propolice) and by instructing the VM to mark executeable pages
non-writeable and writeable pages non-executeable (W^X support is it
called). There are problems though since the method only up the ante for
an eventual attack. 

Compilers for languages like OCaml and SML does it by enforcing strict
types and does bounds-checking on all array access. When the compiler
can prove the bound unneeded (which is often can), then it removes the
bounds check altogether since it could be solved at compile-time. The
problems arising with this solution are attacks from type-checking to
run of the program (although theoretical), high-level languages without
explicit control of memory and like problems. 

Cyclone tries to bridge the gap between ML-like languages with all their
safety measures and C with the explicit control of the memory layout. It
seems they do not do garbage collection but does Region inference
instead[1], which is a solution I welcome. Region inference has better
real-time proved bounds than garbage collection has. 

I hope Cyclone succeeds. When semantical and compiler theory makes it
possible to leverage work from the programmer once and for all, and the
theory is so simple it can be implemented, then why not do it?

[1] - Mads Tofte did research on this a couple of years ago:
   http://www.diku.dk/users/tofte/publ/publ.html

-- 
j.