It also most definitely does not include anything even close to weak_ptr.

Are you sure? When reading it through, it looked like ptr<T> was designed to NULL out when the original data was invalid. That is the functionality from std::weak_ptr<T> that would be very nice.

No. This doesn't solve anywhere near enough real problems compared to just using modern C++.

C++ can't solve this issue because it itself is based upon potentially dangerous C libraries. As a library consumer, C++ (even Java and C#) seem better than C but remembering that underneath all their hoods, the same dangers can (and almost certainly do) still lurk, it removes all the fun ;). Plus these languages end up running more C than a C program due to their additional layers written in C so they are still not ideal.

Checked C aims to remove these issues at a much lower level than possible by just bolting on another random language.

The paper says it is about bounds-checking. a weak_ptr has nothing to do with bounds checking. The introduction is entirely about bounds-checking. It mentions problems such as using already-deleted memory are beyond the scope of Checked C.

C++ can at least partially solve the issue, because you can use templates to create the checked pointer classes. That's what the team who made this did as a prototype.

Just building with Checked C instead of C gets you nothing. You have to use the new types. Converting one of those potentially dangerous libraries to Checked C means putting in the correct changes to use bounds-checking everywhere they would belong, and making no mistakes or oversights while doing so. As long as you're rewriting chunks of the library, why not rewrite them in C++? What's the difference? How does the library go from potentially dangerous to knowing it's safe? How do you know you did the conversion correctly? How do you know the library isn't dangerous because of something that wasn't covered, like memory allocation?

If, for some reason, you have a code base that's in C, and you're willing to rewrite every part of it that uses pointers, and compiling it in C++ scares you and/or you're not willing to create the helper templates yourself, but compiling it in a new version of C from Microsoft is something you're willing to do, and you're having trouble with buffer overflows, and compile-time checks will help or run-time crashing is ok, than sure, Checked C might solve a problem for you.

Very little of any software "has to be" written in C anymore.

Entire huge games have been shipped with no C in them, for example. Of the things you listed, the C implementation is usually for compatibility with non-C languages, not to espouse C directly!

I have an entire language and compiler toolchain written with 0 dependencies on raw C. It has support for speaking the C ABI, but that has nothing to do with the C language being a mandatory component of anything.

The pieces of software that are in C are usually some of the most hardened and well-tested portions, for several reasons - not least of which being the fact that they usually exist to interface with non-C languages.

The effort of rewriting C code into Checked C is nontrivial. The reward is marginal at best for already-bulletproofed code. I just don't see a compelling reason for adoption.


It's a nifty project from a languages standpoint, but I don't see it being revolutionary.

And of course, if it "has to be" written in C, you cannot write it in Checked C.

The whole thing has bothered me from the start of this thread. I have had this little voice in the back of my head "it's the embrace and extend trick! watch out!", but while it's definitely a possibility, let's assume they really want a better C.

Philosophically, the C language trusts the programmer, and in my view, this is why C is so popular. I get total control over the code. In low level code or really high performant code, I want that control, since I am in a hurry. The compiler shouldn't add extra stuff that I didn't program. C in itself is not a nice language for building really large and complicated programs[1]. Like others have said already, unless you need that much control, other languages are often better for the task.

Now Checked C breaks that idea. The compiler adds bounds-checking code at every point where I use a special type (as far as I understood). So even if I have super-long thought about some point in the code, and it's really fine, and I wrote a proof, published it, and got a Nobel prize for it, even then the compiler can decide to add a check, since it didn't read my proof.

This goes so much against the idea behind C, that in my view, calling it <anything>-C, is just plain wrong.

To me, this makes the name "Checked C" just a cheap marketing trick to position the language.

Then the implementation. You make a new language ("embrace and extend C"!). As others have said, that defeats the purpose. The current eco-system is C. If you want to improve C code, making a new incompatible language doesn't work. People are not going to re-implement the zillions of C code lines, unless MS starts requiring that from their suppliers. "All new drivers must be in Checked C". Well, at least that would work for embrace and extend :P

I think a much better approach is to give the programmers more information and to educate them. They don't intentionally add exploits, they just fail to see the possibility. Build a really good analysis tool to point out the problems. Give warnings when you don't find counter-proof. Write articles about "better safe than sorry", "reliability is more important than

performance" (most times), and how to minimize impact on performance. Show that with good branch prediction, it's close to 0, so there isn't much reason not to do it. It would just fit in the current eco-system, and educate programmers about todays CPUs, and customer needs (which unlike what we believe is mostly not about performance, I think).

This would however be a much larger effort, and possibly have less impact, than bluntly just adding checks everywhere, and destroying some performance without actual need.

Maybe we should give up on that total control, and move on beyond C. I don't expect that to happen for another 20-30 years, tbh.

In that case however, "Checked-C" is a wrong name too :)

[1] Yes exceptions exist, both good ones and bad ones.