<story><title>Proposal for a Friendly Dialect of C</title><url>http://blog.regehr.org/archives/1180</url></story><parent_chain></parent_chain><comment><author>Verdex</author><text>I think it&amp;#x27;s interesting that the famous tech companies are all developing programming languages that are less managed than java&amp;#x2F;c#, but more predictable (read: less undefined behavior) than c&amp;#x2F;c++.  Facebook seems interested in D, Apple has Swift, Microsoft has some sort of secret project they are working on, Google has Go, and Mozilla has Rust.  Even c++ seems to be attempting to modernize with the new additions to it&amp;#x27;s spec. And now we see a desire for c itself to change.  I wonder if our industry is at a turning point where managed languages aren&amp;#x27;t quite cutting it, but no one is comfortable going back to the &amp;#x27;good old days&amp;#x27;.&lt;p&gt;On a personal note, I like the idea of friendly C so much that I finally made an HN account.  One of my favorite things to do is to take things apart and understand them.  I was mortified when I learned the real meaning of undefined behavior in c&amp;#x2F;c++.  It seems like the only way to be sure you understand a C program is to check the generated machine code.  Even worse is that when I try to talk to other developers about undefined behavior, I tend to get the impression that they don&amp;#x27;t actually understand what undefined behavior means.  I can&amp;#x27;t think of a way to verify what they think it means without insulting their intelligence, but hopefully the existence of something like friendly C will make it an easier discussion to have.</text></comment>
<story><title>Proposal for a Friendly Dialect of C</title><url>http://blog.regehr.org/archives/1180</url></story><parent_chain></parent_chain><comment><author>userbinator</author><text>I really like these suggestions since they can be summed up in one sentence: they are what C programmers who write code with UB would already expect any reasonably sane platform would do. I think it&amp;#x27;s definitely a very positive change in attitude from the &amp;quot;undefined behaviour, therefore &lt;i&gt;anything&lt;/i&gt; can happen&amp;quot; that resulted in compilers&amp;#x27; optimisations becoming very surprising and unpredictable.&lt;p&gt;&lt;i&gt;Rather, we are trying rescue the predictable little language that we all know is hiding within the C standard.&lt;/i&gt;&lt;p&gt;Well said. I think the practice of UB-exploiting optimisation was completely against the spirit of the language, and that the majority of optimisation benefits happen in the compiler backend (instruction selection, register allocation, etc.) At least as an Asm programmer, I can attest that IS&amp;#x2F;RA can make a &lt;i&gt;huge&lt;/i&gt; difference in speed&amp;#x2F;size.&lt;p&gt;The other nice point about this friendly C dialect is that it still allows for much optimisation, but with a significant difference: instead of basing it on assumptions of UB defined by the standard, it can still be done based on proof; e.g. code that can be proved to be unneeded can be eliminated, instead of code that may invoke UB. I think this sort of optimisation is what most C programmers intuitively agree with.</text></comment>