Pondering the X client vulnerabilities

Posted May 30, 2013 20:48 UTC (Thu) by kleptog (subscriber, #1183)
In reply to: Pondering the X client vulnerabilities by epa
Parent article: Pondering the X client vulnerabilities

The amount of code written in C is so vast that trying to fiddle with basic features of the language (like pointer arithmetic) will simply lead to vast swathes of C code failing to compile. To get people to advance to newer versions of the language requires not leaving a huge percentage of people behind. Witness Python 2 vs 3.

In any case, C doesn't need to become a safe language. There are plenty of safe languages to code in, you need at least one unsafe language to code all the safe languages in. It may as well be C.

What I think would really make a difference is if someone actually implemented a working C-like language (you couldn't call it C) that had a few extra restrictions, like: 'a pointer assigned an address in array X cannot point outside that array by pointer arithmetic'. And then demonstrated that it (a) performed ok and (b) ran >99% of existing C code.

I think the easiest way to achieve this would be code a C interpreter in PyPy where you could implement the restrictions, and you get a JIT to make it perform. If you could make this work, my guess is you could convince a lot of people run most C programs under such an interpreter and you would have solved the problems for a significant portion of the codebase.

But whether its actually achievable....

Pondering the X client vulnerabilities

Posted Jun 5, 2013 10:10 UTC (Wed) by epa (subscriber, #39769) [Link] (1 responses)

Have you looked at Cyclone?

Pondering the X client vulnerabilities

Posted Jun 5, 2013 20:31 UTC (Wed) by kleptog (subscriber, #1183) [Link]

Interesting, but it looks like it just punted and just created a new language that looks like C but isn't. Which means it's never going to catch on because it would require changing the code.

I mean, valgrind manages to catch all sorts of memory errors without any source with not many false positives. ISTM a compiler should be able to do a similar job but more efficiently (because valgrind slow as molasses, but points out the error to you right away, which is what makes it worth it).

Pondering the X client vulnerabilities

Posted Jun 6, 2013 8:55 UTC (Thu) by kevinm (guest, #69913) [Link]

Actually, for the restriction you gave ("a pointer assigned an address in array X cannot point outside that array by pointer arithmetic"), you *could* implement pretty much that restriction and still call it C. In C, pointer arithmetic is only defined if it results in a pointer within the original object or one object past the end of an array.

The major obstacle would be that you'd need an ABI change to pass around the necessary object extent data to enforce this everywhere.