• Advertisement
Sign in to follow this  

Microsoft Checked C

This topic is 665 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Just thought I would share this project with you guys in case you had not come across it yet.

http://www.theregister.co.uk/2016/06/16/microsoft_releases_open_source_bugbomb_in_the_rambling_house_of_c/
https://github.com/Microsoft/checkedc/releases/download/v0.5-final/checkedc-v0.5.pdf
http://research.microsoft.com/en-us/projects/checkedc/default.aspx
https://github.com/Microsoft/checkedc

It looks really interesting. It basically extends the C language to include something similar to std::weak_ptr<T>. Even if a developer does not use C, it is still very relevant to them because 99% of languages are written in C and often when using native libraries (such as OpenGL, SDL etc...) the developer will need a binding (again, written in C). Checked C has a reference implementation using clang and llvm. It basically solves the issue of C being so unsafe and archaic but at the time a critical and necessary underpinning technology.

I developed a similar project called libstent (https://github.com/osen/stent) that tries to achieve the same thing but it uses MACRO hacks instead (however it does also provide exception safety using finalizers). However, having safe functionality built into the language itself is certainly nice to have.

What do you guys reckon? Would you throw away a bit of portability between C compilers to use Checked C? Edited by Karsten_

Share this post


Link to post
Share on other sites
Advertisement

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.

Share this post


Link to post
Share on other sites
Just thought I would explain my interest in Checked C a little bit more. I am not here to recommend writing a game in it, I am suggesting that this could be a great technology to use for the parts of software that are currently needing to be written in ANSI C. For example things like SDL, Mesa, glew, glut, compilers etc...

No matter how much we (effectively the consumers in this context) prefer our own different languages, sooner or later we all depend on a C library that could potentially be made safer by using Checked C.

So things like Rust a C++ would still potentially benefit from Checked C. And that I think is pretty cool.

Rust is written in ~1.6% C (which is a massive amount of code, larger than many games in fact)
The Clang compiler is written in ~21.6% C (again massive and that's forgetting the standard library wrapping a lot of C)

If Checked C can alert us to bugs in these projects, then everyone's a winner :) Edited by Karsten_

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement