[Cryptography] bounded pointers in C

[Jerry Leichter]

On Apr 19, 2014, at 1:21 AM, Nemo <nemo at self-evident.org> wrote:
> In C++, it is trivial to create "SafeInt" and "SafeArray" classes that
> overload addition and dereference, respectively, so that expressions
> like "x+y" check for overflow and expressions like "a[n]" check for
> out-of-bounds access. That so many programmers write security-sensitive
> code without using such simple idioms is hardly the fault of the
> language.
Almost - and the "almost" is what stops people.  Yes, you can have a SafeInt, and it will "work" in most cases.  But you can't, for example, have SafeInt constants.  So you can't have switch statements that switch on SafeInt.  The built-in types have all kinds of special properties (the standard numeric conversions, for example) that a user-defined class can't imitate, but which are a fundamental part of the way C++ code is written.

If you write your code using a SafeInt class to begin with, you can structure it to look nice and work correctly.  (Some of the matrix math classes you can find do an impressive job of making matrix algebra look as if it was built in to C++.)  You'll have to write some explicit conversions and constructor calls where the built-in types didn't require them, but it's probably not too bad.

However, substituting SafeInt for int in an existing code base written using accepted C++ styles would be a huge effort that few would undertake.

Defining effective array-like classes is easier because arrays have much more limited inherent semantics.  The traditional issue has been the lack of a way to write down a constant of an array-like class, as you can an array (though only in limited contexts, i.e., initializers).  I haven't gotten into the details of C++11, but I gather this has gotten a bit easier.

(I've toyed over the years with two notions to make this easier.  The first is the ability to "subclass" the built-in types.  You would be strongly limited on what you could add, but you'd inherit the special conversion semantics and such unless you explicitly overrode it.  The second is to have "const constructors" that produced a compile-time constant.  Obviously, they could only have compile-time-constant parameters, and could only use proper compile-time-constant expressions inside of them.  Never quite got either figured out to the point where I could submit it as a proposal....)
                                                        -- Jerry