[cap-talk] C vs. Safety

[Jonathan S. Shapiro]

On Tue, 2008-08-05 at 10:48 -0400, Jonathan S. Shapiro wrote:
> On Tue, 2008-08-05 at 14:10 +1000, James A. Donald wrote:
>
> > Plus there is a huge amount of software in C, most of it
> > woefully insecure, that is *not* going to move to a
> > managed code environment.
> 
> I'm not convinced of this, but I will address this in a separate note.

Let me qualify that. I'm certain that we aren't going to see a grand
migration of existing C code to managed environments, but I'm prepared
to believe that we may see an increasing number of libraries that are
willing and able to operate safely, and could therefore be deployed in a
managed environment without change.

While C as a language is certainly unsafe, the majority of programs
written in C *are* safe if idiomatic analysis is applied. More
precisely: they intend to be safe and violations of that intent would be
considered a bug. In fact, it appears that a significant proportion of C
programs could be automatically translated into BitC without loss of
meaning.

Now that translation certainly will not occur, but it is very possible
to imagine a restricted subset of C that guarantees safety and remains
compilable by an ANSI C compiler, and it is possible to imagine that
this subset would come to see wide use -- if only for the sake of
maintainability.

There are serious attempts underway to achieve this, notably MISRA C.
MISRA C in particular is horribly misguided and misdirected. My point in
mentioning it is that there is a very substantial community out there
that is looking for a viable solution to the problem of C, and is
willing to undertake some serious restriction of the language to get it.

Then there are things like SafeCode, which compiles existing C code into
a dynamically safe (via checks) executable, and Deputy, which can
achieve a lower rate of dynamic checks through annotation.

The goal, of course, is *static* safety, and that is considerably harder
to achieve. Still, it isn't unimaginable.


shap