[Cryptography] bounded pointers in C

Jerry Leichter leichter at lrw.com
Sat Apr 19 22:27:11 EDT 2014


On Apr 19, 2014, at 1:54 PM, Nemo <nemo at self-evident.org> wrote:
>> 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.
> 
> Of course you can have SafeInt constants, just like you can have any
> other type of const object:
> 
> static const SafeInt twelve(12);
So now rather than writing:

	s = 12 * s;

where s is a SafeInt, I have to first define a variable to hold 12?  Sorry, but no.

> You can also provide an implicit cast-to-int operator that will let you
> use your SafeInt in a "switch" statement.
Yes, and you can provide automatic conversions back and forth between int's and SafeInt's in all kinds of contexts.  The 12 * s issue above could be dealt with by having an operator *(int, SafeInt).  But once you provided too many conversions - in particular *any* implicit conversions from a SafeInt back to an int - you potentially lose the safety of SafeInt!  There's the potential that at some point what you thought was SafeInt arithmetic is actually turned into int arithmetic.

> Live example: http://goo.gl/ds4AZx
> 
> Since int and SafeInt can cast to/from each other transparently, it is
> easy to imagine converting an existing code base from to the other
> incrementally.
I have never seen a successful effort to incrementally update a code base like this.  Maybe someone's managed to do it.

>> 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.
> 
> Perhaps there are useful properties of "int" that "SafeInt" cannot
> imitate, but your examples so far do not demonstrate any.
The easiest example:  Look at the rules for type conversions in determining matching functions.  The compiler can (in principle) apply any number of built-in conversions (in practice, because of the set of built-in conversions available, the number is small, but definitely greater than 1 - e.g., widen char to int, then convert to float).  However, it can *never* implicitly apply more than one user-defined conversion.  You can try and get around some of this by defining more overloads - but if you have too many overloads, overload resolution becomes ambiguous (there are pairs of overloads neither of which strictly dominates the other in the partial ordering of potential overload resolutions that the Standard defines) and then your program fails to compile.

Been there, done that, been bitten.  (In fact, I've actually used this mechanism to force deliberate ambiguities to keep people from accidentally accessing the "wrong" function.)
                                                        -- Jerry



More information about the cryptography mailing list