
Checked C: Making C Safer by Extension - matt_d
https://www.microsoft.com/en-us/research/publication/checkedc-making-c-safe-by-extension/
======
Someone
This does nothing for use-after-free or integer under/overflow, so “Making C
Safe _R_ by Extension” would be a better title.

It’s good to see people attempting this, though. I would think chances are
good Microsoft will use it internally, and that already would be a win. Also,
it’s a clang/LLVM extension. That makes it easier for third parties to start
using it.

On the other hand, their choice to use _Ptr <T>_ for familiarity with C++
requires users who want to keep their code compatible with C compilers that
don’t support this a bit harder (it will require wrapping that in some macro,
say __ptrTo(T)_ ). That isn’t ideal for adoption in open source programs.

~~~
ainar-g
Re. syntax. I don't understand, why can't they just make _Ptr an attribute
like _Atomic, and provide a header <stdchecked.h>. That is,

    
    
      #include <stdchecked.h>
    
      void read_next(int *b, int idx, checked int *out) {
          int tmp = *(b+idx);
          *out = tmp;
      }

------
saagarjha
The problem here is you’re not writing C, you’re writing a language that kind
of resembles C but is nonportable. So you might as well just use a different,
memory safe language at that point.

~~~
chubot
I think you're missing an important point:

 _Checked C’s design is distinguished by its focus on backward-compatibility,
incremental conversion, developer control, and enabling highly performant
code_

The problem is that there is a huge body of decades-old C code out there that
we all depend on.

A typical Docker container with a web app contains maybe 10K lines of your own
code in Python/Ruby/JS, 100K lines of framework code, and 1M or 10M lines of C
code (i.e. the interpreter itself, the web server, SSL, the base image, etc.)

So I welcome new languages focused on incremental conversion.

That's what I'm doing with Unix shell:
[http://www.oilshell.org/blog/2018/01/28.html](http://www.oilshell.org/blog/2018/01/28.html)

I applaud projects like Corrode, a C to unsafe-Rust translator, although
undoubtedly they would have an easier time if Rust was designed in the first
place for conversion.

[https://github.com/jameysharp/corrode](https://github.com/jameysharp/corrode)

So Checked C seems like a great idea to me.

I've noticed that most programmers seem to wildly overestimate the rate at
which code gets rewritten. I think it's more accurate to say that code piles
up over time. And unfortunately when the foundations are unstable, what you
build on top is also unstable.

~~~
bluejekyll
There is also a new tool, c2rust, [https://c2rust.com](https://c2rust.com)
that I believe was inspired by Corrode.

In addition, we also have the bindgen tool in Rust that will auto generate the
Rust FFI from C header files. It works really well. At that point you wrap the
FFI in more Rust idiomatic interfaces, and expose those as the preferred
library for others to use.

I mention this, because it is a path toward allowing for the carrying forward
of a C codebase, but using a safe language like Rust for all future work,
perhaps going back and rewriting the C if it’s deemed important.

There are many examples of this pattern being applied to projects.

In addition to that, there is a cbindgen tool, that does the inverse of the
bindgen tool, which would allow you to write Rust code, and quickly generate C
header files for the FFI, allowing for critical areas of C to be replaced with
Rust, without converting the entire project.

Putting all of that together might be a reasonable thing for large projects to
convert iteratively, should they decide it’s an important thing for them to
do.

~~~
pjmlp
That is nice for userspace apps, but no one is going to use c2rust on Aix, HP-
UX, __*BSD, Linux, Zephyr, QNX, RTos, ....

I think something like Checked C is the only way to actually make it work on
those use cases.

~~~
littlestymaar
No one is going to use Rust on any of these projects, because of political
reasons and portability concerns (because LLVM doesn't target all platforms).
But those two issues also apply to Checked C and I doubt any project you
listed will ever use it either.

~~~
sanxiyn
Since BSD's system compiler is now LLVM, I think it's only a matter of time
some enlightened BSD variant (OpenBSD maybe?) tries something like Checked C.

------
profquail
Checked C source code:
[https://github.com/Microsoft/checkedc](https://github.com/Microsoft/checkedc)

------
Animats
I wonder how this will work out. GCC had checked fat pointers for years, used
by almost nobody. Microsoft can make it stick on their platform, because they
own the libraries and can make them use fat pointers.

I hope this works out better than Microsoft Managed C++.

~~~
wott
There has been dozens of "safe" additions, variants and extensions to C along
the years (from commercial companies, from individuals, from university labs,
...). Not one of them ever took off. This one did not either.

We always just say "hmmm... right... this one may look a bit better than the
previous one (or doesn't)" and we never bother to use them. After 20 years
like this, we can conclude that we like C as it is and are not interested in
extra layers.

~~~
stefano
> After 20 years like this, we can conclude that we like C as it is and are
> not interested in extra layers.

This says a lot about how little the industry cares about software quality.
You'd think a bunch of people who make a living out of automating tasks would
happily use tools that automate the checking of an importnt source of bugs.
Instead, many prefer to use tools that look simpler on the surface and then
end up manually testing for the same kind of bugs over and over. So you have
people writing in dynamically typed languages who rely on (manually written!)
unit tests to check that their program is not mixing up types, and others
using unsafe languages and then relying on tests to catch memory access
violations. Inevitably, tests never catch all issues and you end up with type
errors and segfaults in production.

~~~
vmchale
> This says a lot about how little the industry cares about software quality.
> You'd think a bunch of people who make a living out of automating tasks
> would happily use tools that automate the checking of an importnt source of
> bugs. Instead, many prefer to use tools that look simpler on the surface and
> then end up manually testing for the same kind of bugs over and over. So you
> have people writing in dynamically typed languages who rely on (manually
> written!) unit tests to check that their program is not mixing up types, and
> others using unsafe languages and then relying on tests to catch memory
> access violations.

In the case of a "safer C" I suspect it's largely because it never
materialized. C still has its deficiencies relative to Rust, but Rust is the
first viable competitor.

~~~
pjmlp
Sure it did, all major systems languages outside UNIX universe were safer than
C.

But the OSes they were tied to were killed by UNIX's adoption, just like the
browser has helped JavaScript to take over areas of other languages.

------
kyberias
October 1, 2018 ? :O

~~~
srujn
That's likely when the paper will be presented at the
[https://cybersecurity.ieee.org/blog/2018/01/31/ieee-
secdev-2...](https://cybersecurity.ieee.org/blog/2018/01/31/ieee-
secdev-2018-call-for-papers/)

------
styfle
There is some precedent for a new language that gradually improves safety of
an existing language; TypeScript did this to JavaScript and is arguably
successful.

I don’t know if Checked C will have the same success story but if devs can
easily add this to their existing projects and it catches bugs, that seems
like a win to me.

