[Cryptography] Ada vs Rust vs safer C

[Henry Baker]

At 01:31 PM 9/16/2016, Arnold Reinhold 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?
>
>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.
>
>Building a safer C seems more doable than converting massive amounts of C code, and programers, to new languages.

Terrific idea, but how do you keep such a project under control?

Even if you can get such a project started, the biggest issue becomes *mission creep*.

People get so enamored with the project & process that they forget why they're there.

Ideally, this is a project of *one*, or at most *two* people, which then gets a prototype compiler implemented by an extremely small team in a relatively short time.

IMHO, the main things to do are to remove certain features and to standardize certain other common practices.

Also, recognize that we now have huge memories, & so remove many ancient limitations -- e.g., size of identifiers, character sets, expression sizes & depths, pre-processor limitations, etc.

The language is a *subset* of existing C, but far more portable and easier to deal with w/o arbitrary limitations.  It should be possible to make existing programs "look" like your new standard, through appropriate C preprocessor macros.

Perhaps the most obvious remaining non-portability should be big-endian v. little-endian.  I see no non-visible way to eliminate these differences.

You'll have Intel/AMD lining up against ARM & MIPS contingents to try to their favorite architectures; you need to raise funds from all contenders to keep it neutral.