[Cryptography] Ada vs Rust vs safer C

Florian Weimer fw at deneb.enyo.de
Sat Sep 17 11:55:05 EDT 2016


* Ron Garret:

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

Just type-safe array slice type (which has address and length) would
be a big help to many developers.  A natural way to write saturating
arithmetic or conditions evaluated to infinite precision would be
rather convenient for low-level code, too.  (You don't need to care
that much about integer overflow if you have decent memory structures
and APIs to access them, but someone still needs to write *their*
internals.)

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

Existing compilers already track pointer provenance information, the
syntactic separation isn't really required.

But those are still language changes, and you need changes in
programmer attitude to see adoption.  For example, both glib and C++
provide arrays-with-bounds, but the implementations do not check them.
The C++ standard has both operator[](size_type) and at(size_type), so
the programmer can choose between having and not having overflow
checks.

So I think we just need the magic, ABI-compatible safe C
implementation.


More information about the cryptography mailing list