[Cryptography] Ada vs Rust vs safer C

[Ray Dillinger]

On 09/16/2016 04:01 PM, Watson Ladd wrote:

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

There was an effort called 'simple c' which attempted to do that IIRC.
But it became bogged down in the question: what do different developer
communities consider to be the _correct_ specification for various bits
of unspecified behavior?  There was far less agreement than expected.

As far as I'm concerned, most of 'undefined behavior' should be defined
either as 'compiler halts with an error' or 'compiled program contains
code to detect this and halt instantly if it happens.'

IE, code that is valid and has specified behavior in the new dialect
should for the most part be a subset of valid code with the same
specified behavior in C.

Otherwise I'd far prefer to have the new dialect absolutely require
something that flatly will not be accepted by other C compilers (which
could be just a 'dialect declaration' at the head of the file).
Otherwise people will use everything else in the world to compile it
because "It's just C code, right?"  and things will go awry because code
written to the new 'extended standard' will be silently depending on
things that other compilers will do differently or not at all.

There are several cases where 'compiler halt or program crash' is
clearly wrong, too - Integer overflow for example should not be
undefined and it should not be a crashing error.  I consider it
'obvious' that

C = A + B;  /* overflow is unspecified on integer addition */

should have the same semantics as

/* overflow on unsigned integers is specified as wraparound to zero,
   and therefore this expression does "what you expect" of integer
   addition with both integers and unsigned integers represented
   in 2s complement; wraps around to the most negative value. */

C = (int)((unsigned int)A + (unsigned int)B);

but a compiler proceeding on the basis that either an accurate
(non-overflow) addition happened, or undefined behavior, can decide it
has the right to skip any code which could only be activated by the
undefined behavior - such as a check for inaccurate (with-overflow)
addition.

> What would it then take to develop compiler
> that meets those specifications? 

Not much, actually; tcc with optimizations turned off already meets most
of them with what people would consider 'obvious' semantics.  Because
it's not 'compiler halts' or 'program crashes' however, code developed
under tcc dies horribly or develops obscure and unexpected bugs when
compiled anywhere else.

I've been going the other way mostly; I've been developing under gcc
specifically to make any unspecified-behavior bugs as much worse as
possible, because that way I don't inadvertently depend on crap
assumptions so much.  gcc is cool like that.  Then I actually use
something else to compile any code I send to clients.  Porting the
code away from gcc sometimes reveals unspecified stuff too - gcc'isms I
accidentally depended on.  Once code is hammered down enough to do the
right thing on a couple of different compilers, it's potentially ready
for use.

>> Building a safer C seems more doable than converting massive amounts of C
> code, and programers, to new languages.

True that.  Mostly I think what you want to do for this purpose is to
fork tcc and enshrine most of its default behaviors for unspecified C in
your new standard.  I would prefer compiler halt or program halt in most
cases, but if you want "obvious" instead, that's probably a very close
approximation to it.

				Bear


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160917/39c7fe06/attachment.sig>