
Checked C - ingve
https://kristerw.blogspot.com/2016/07/checked-c.html
======
bluejekyll
I'm torn. I suppose it's easier to upgrade existing code bases to this, but it
won't fix code locations that are improperly upgraded to this language. Which
in my opinion means that The C code will still have lurking errors.

Also: "either (1) the operation must convert that value to an in-range integer
value or (2) the expression shall produce a runtime error"

Is more defined, but does not actually help you much, because this will depend
on platforms, and a overflow to 0 might produce similar issues when indexing
as other errors today in creating bugs in encryption algorithms.

If we all agree that C is not a safe language, and that we'd all prefer
writing in a safe language, then why not write in a safe language, e.g. Rust.

An aside: I've recently done a project where I explored replacing C library
functions with Rust implementations, linking in the Rust library directly to
the existing C library. I was very pleasantly surprised at the ease of doing
this! This means that we really can migrate away from C in an iterative
fashion, just as Checked C would allow us to do.

------
rwmj
Since my paper on Bounds Checking C (Jones & Kelly, 1997) was mentioned in
their bibliography, I've put my original 1995 BSc report that started the
whole thing here:

[http://oirase.annexia.org/bounds/](http://oirase.annexia.org/bounds/)

Original was a MS Word 6 document (!)

------
Animats
Didn't we just cover this on HN?

It's sort of halfway between C and C++, with constructs like

    
    
        array_ptr<T>

