<p dir="ltr">On Sep 16, 2016 7:38 PM, "Ron Garret" <<a href="mailto:ron@flownet.com">ron@flownet.com</a>> wrote:<br>
><br>
><br>
> On Sep 16, 2016, at 1:31 PM, Arnold Reinhold <<a href="mailto:agr@me.com">agr@me.com</a>> wrote:<br>
><br>
> > In the recent thread on safe erasure in C,  much was made of better languages including Ada and Rust. But there is a vast mount of code already written in C. Converting all of it or even a large fraction seems hopeless. For comparison what would it take to make a safer C?<br>
><br>
> Not much.  It’s actually a lot easier to make a safer C than it is to make a faster C.<br>
><br>
> > To begin with, many of the problems with unsafe code generation have to do with the large number of undefined behaviors in C.  Since the dogma is that undefined means the compiler can do anything its developers want, what would it take to develop a supplemental specification that defines the most concerning undefined behaviors? What would it then take to develop  compiler that meets those specifications? If the Free Software Foundation might be convinced to help. If not, GCC, or parts of it, could be forked. There must be some programmers out there with compiler chops that would find this kind of project interesting. Perhaps a Kickstarter campaign might be helpful. Defining undefined behavior shouldn’t affect most existing programs.<br>
><br>
> I would not start with gcc, I would start with tcc.  In fact, simply using tcc instead of gcc is probably already a huge win.<br>
><br>
> > Building a safer C seems more doable than converting massive amounts of C code, and programers, to new languages.<br>
><br>
> There’s a boatload of low-lying fruit.<br>
><br>
> 1.  Simply warning about all detected undefined behavior (instead of silently emitting stupid code) would be huge win.</p>
<p dir="ltr">That's not what compilers are doing. They carry out transformations valid in the absence of undefined behavior. Really the only big one here is signed overflow, for which there already is a gcc flag to wrap and some compilers will trap.</p>
<p dir="ltr">><br>
> 2.  Treating all lvalues as if they were volatile (i.e. not even trying to optimize anything, just a completely straightforward translation of C into assembly) would likewise be a huge win.</p>
<p dir="ltr">Has this lead to security bugs? No. Forget the nonsense of secure erasure and realize operating systems clear memory between users and programs. </p>
<p dir="ltr">><br>
> 3.  If you really want to win big, have your compiler distinguish internally between T* v and T v[c], and likewise distinguish between *(v+offset) and v[offset], and add bounds checking in the latter case.  Yes, this violates the C standard, but so what?  The C standard is stupid.</p>
<p dir="ltr">Please cite chapter and verse. Bounds checking is legal as the C memory model is not a flat address space. The keyword is derived pointer: you can only legitimately access a memory region through pointers created certain ways.</p>
<p dir="ltr">><br>
> 4.  If you really REALLY want to win big, define a new language that is just like C but where v[offset] and *(v+offset) are NOT equivalent operations, and deprecate the latter.</p>
<p dir="ltr">What semantics do you want here?<br>
><br>
> rg<br>
><br>
> _______________________________________________<br>
> The cryptography mailing list<br>
><a href="mailto:cryptography@metzdowd.com"> cryptography@metzdowd.com</a><br>
><a href="http://www.metzdowd.com/mailman/listinfo/cryptography"> http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</p>