[Cryptography] Ada vs Rust vs safer C

[Watson Ladd]

On Sep 16, 2016 7:38 PM, "Ron Garret" <ron at flownet.com> wrote:
>
>
> On Sep 16, 2016, at 1:31 PM, Arnold Reinhold <agr at me.com> wrote:
>
> > 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?
>
> Not much.  It’s actually a lot easier to make a safer C than it is to
make a faster C.
>
> > 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.
>
> 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.
>
> > Building a safer C seems more doable than converting massive amounts of
C code, and programers, to new languages.
>
> There’s a boatload of low-lying fruit.
>
> 1.  Simply warning about all detected undefined behavior (instead of
silently emitting stupid code) would be huge win.

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.

>
> 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.

Has this lead to security bugs? No. Forget the nonsense of secure erasure
and realize operating systems clear memory between users and programs.

>
> 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.

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.

>
> 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.

What semantics do you want here?
>
> rg
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160917/b923af96/attachment.html>