<story><title>Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]</title><url>http://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-preprint.pdf</url></story><parent_chain><item><author>jasode</author><text>This is a long paper and the author has 2 main claims:&lt;p&gt;1) C Language popularity is more to do with cognitive ease of &lt;i&gt;memory addresses&lt;/i&gt; as a conceptual model for inspection and change.  Author claims memory address mental model overshadows &lt;i&gt;runtime performance&lt;/i&gt;.&lt;p&gt;2) switching to &amp;quot;safe&amp;quot; languages like Java&amp;#x2F;C#&amp;#x2F;Rust is not necessary.  With no changes&amp;#x2F;violations to existing C Language specification, a new&amp;#x2F;different &lt;i&gt;implementation&lt;/i&gt; (compiler) can add more runtime safety checks similar to &lt;i&gt;managed&lt;/i&gt; languages.  An example from the paper:&lt;p&gt;&lt;i&gt;&amp;gt;Consider unchecked array accesses. Nowhere does C define that array accesses are unchecked. It just happens that implementations don’t check them. This is an implementation norm, not a fact of the language.&lt;/i&gt;&lt;p&gt;Those 2 ideas look orthogonal but he ties them together at the end.&lt;p&gt;I&amp;#x27;ll take some poetic license (e.g. a little exaggeration) to reword the author&amp;#x27;s idea to help spur discussion...&lt;p&gt;Consider the idea of the &lt;i&gt;Sufficiently Smart Compiler&lt;/i&gt;[1] that claims that a &amp;quot;slow&amp;quot; and &amp;quot;high-level&amp;quot; language like Python&amp;#x2F;Ruby could be &lt;i&gt;theoretically&lt;/i&gt; analyzed and compiled to be as fast as C or handcrafted assembly.&lt;p&gt;In a way, the author is coming from the opposite direction.  If you had a &lt;i&gt;&amp;quot;Sufficiently Smart Runtime&amp;quot;&lt;/i&gt; for a new C Language compiler implementation, it could (theoretically) do all sorts of extra checks and bookkeeping that wouldn&amp;#x27;t require any changes to C source code and wouldn&amp;#x27;t violate the existing C Language standard.  (E.g. Imagine a new C runtime that did many checks similar to Valgrind + UBSAN + ASAN + debugger memory fences, etc.)&lt;p&gt;Would the program execution be slower?  Well yes, but that&amp;#x27;s not really an issue because according to author&amp;#x27;s claim #1, what programmers really like about C is the mental ease of accessing memory addresses.  The performance is important, but it&amp;#x27;s a secondary benefit -- according to the author.&lt;p&gt;[1] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;wiki.c2.com&amp;#x2F;?SufficientlySmartCompiler&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;wiki.c2.com&amp;#x2F;?SufficientlySmartCompiler&lt;/a&gt;</text></item></parent_chain><comment><author>nickpsecurity</author><text>The problem is that it isn&amp;#x27;t a new idea. People keep trying it as shown below. Unfortunately, C wasn&amp;#x27;t designed so much as a modified version of something (BCPL) that was the only collection of features Richards could get to compile on his crappy hardware. It&amp;#x27;s not designed for easy analysis or safety. So, all the attempts are going to hit problems in what legacy code they can support, their performance, or even effectiveness if about reliability&amp;#x2F;security in a pointer-heavy language. Compare that to Ada, Wirth&amp;#x27;s stuff, or Modula-3 to find they don&amp;#x27;t have that problem or have much less of it because they were &lt;i&gt;carefully designed&lt;/i&gt; balancing the various tradeoffs. Ada even meets author&amp;#x27;s criteria for safe language with explicit memory representation despite him saying safe languages don&amp;#x27;t have that.&lt;p&gt;To back that up with references, first is a bunch of attempts at safer C&amp;#x27;s or C-like languages with performance issues. The next two are among most recent and practical at memory safety for C apps far as CompSci goes. The last one is an Ada book that lists by chapter each technique its designer used to systematically mitigate bugs or vulnerabilities in systems code.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;pdfs.semanticscholar.org&amp;#x2F;a890&amp;#x2F;a850dc78e65e26f8f4def435b17094ce08cf.pdf&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;pdfs.semanticscholar.org&amp;#x2F;a890&amp;#x2F;a850dc78e65e26f8f4def4...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;llvm.org&amp;#x2F;pubs&amp;#x2F;2006-06-12-PLDI-SAFECode.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;llvm.org&amp;#x2F;pubs&amp;#x2F;2006-06-12-PLDI-SAFECode.html&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.cs.rutgers.edu&amp;#x2F;~santosh.nagarakatte&amp;#x2F;softbound&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.cs.rutgers.edu&amp;#x2F;~santosh.nagarakatte&amp;#x2F;softbound&amp;#x2F;&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;www.adacore.com&amp;#x2F;uploads&amp;#x2F;technical-papers&amp;#x2F;SafeSecureAdav2015-covered.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.adacore.com&amp;#x2F;uploads&amp;#x2F;technical-papers&amp;#x2F;SafeSecureAd...&lt;/a&gt;</text></comment>
<story><title>Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]</title><url>http://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-preprint.pdf</url></story><parent_chain><item><author>jasode</author><text>This is a long paper and the author has 2 main claims:&lt;p&gt;1) C Language popularity is more to do with cognitive ease of &lt;i&gt;memory addresses&lt;/i&gt; as a conceptual model for inspection and change.  Author claims memory address mental model overshadows &lt;i&gt;runtime performance&lt;/i&gt;.&lt;p&gt;2) switching to &amp;quot;safe&amp;quot; languages like Java&amp;#x2F;C#&amp;#x2F;Rust is not necessary.  With no changes&amp;#x2F;violations to existing C Language specification, a new&amp;#x2F;different &lt;i&gt;implementation&lt;/i&gt; (compiler) can add more runtime safety checks similar to &lt;i&gt;managed&lt;/i&gt; languages.  An example from the paper:&lt;p&gt;&lt;i&gt;&amp;gt;Consider unchecked array accesses. Nowhere does C define that array accesses are unchecked. It just happens that implementations don’t check them. This is an implementation norm, not a fact of the language.&lt;/i&gt;&lt;p&gt;Those 2 ideas look orthogonal but he ties them together at the end.&lt;p&gt;I&amp;#x27;ll take some poetic license (e.g. a little exaggeration) to reword the author&amp;#x27;s idea to help spur discussion...&lt;p&gt;Consider the idea of the &lt;i&gt;Sufficiently Smart Compiler&lt;/i&gt;[1] that claims that a &amp;quot;slow&amp;quot; and &amp;quot;high-level&amp;quot; language like Python&amp;#x2F;Ruby could be &lt;i&gt;theoretically&lt;/i&gt; analyzed and compiled to be as fast as C or handcrafted assembly.&lt;p&gt;In a way, the author is coming from the opposite direction.  If you had a &lt;i&gt;&amp;quot;Sufficiently Smart Runtime&amp;quot;&lt;/i&gt; for a new C Language compiler implementation, it could (theoretically) do all sorts of extra checks and bookkeeping that wouldn&amp;#x27;t require any changes to C source code and wouldn&amp;#x27;t violate the existing C Language standard.  (E.g. Imagine a new C runtime that did many checks similar to Valgrind + UBSAN + ASAN + debugger memory fences, etc.)&lt;p&gt;Would the program execution be slower?  Well yes, but that&amp;#x27;s not really an issue because according to author&amp;#x27;s claim #1, what programmers really like about C is the mental ease of accessing memory addresses.  The performance is important, but it&amp;#x27;s a secondary benefit -- according to the author.&lt;p&gt;[1] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;wiki.c2.com&amp;#x2F;?SufficientlySmartCompiler&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;wiki.c2.com&amp;#x2F;?SufficientlySmartCompiler&lt;/a&gt;</text></item></parent_chain><comment><author>ChuckMcM</author><text>Excellent, I think the author would do well to re-frame the question as you have. If nothing else to put it more clearly into the space of provable compilation.&lt;p&gt;When I transferred into the &amp;quot;Oak&amp;quot; group that later became the &amp;quot;Java&amp;quot; organization, the team I was on was looking at whether or not you could write an OS in Java sort of in spite of its safety rules. This sort of concept has been revisited by Rust with its safe&amp;#x2F;unsafe modal operation.&lt;p&gt;What both of those efforts have in common is that determining safety may be impossible at the construct level but provable if you were to exhaustively search all possible outcomes.&lt;p&gt;What the paper and your comment add to the discussion is the intriguing idea that you could create a &amp;#x27;safe&amp;#x27; backend (say the equivalent of the JVM) as a target for a C compiler. And code that could not be compiled would be flagged for later analysis. Much like VHDL can express hardware that cannot by synthesized you might end up with a C compiler that could compile code that could not be executed. I could be fun to spend a bit of time poking around that rabbit hole.</text></comment>