Re: [boost] updated version of safe integer library

Subject: Re: [boost] updated version of safe integer library
From: Noah (duneroadrunner_at_[hidden])
Date: 2016-02-03 15:26:32

On 12/22/2015 9:09 AM, Robert Ramey wrote:

> Of course I'm interested any feedback and/or observations anyone want's
> to offer.

Hey there,

First let me say that I haven't tried out your library yet, but from 
what I've read I think it's great.

So I stumbled upon the comments in your default constructor:

     // default constructor
     constexpr explicit safe_base() {
         // this permits creating of invalid instances.  This is inline
         // with C++ built-in but violates the premises of the whole library
         // choice are:
         // do nothing - violates premise of he library that all safe 
objects
         // are valid
         // initialize to valid value - violates C++ behavior of types.
         // add "initialized" flag.  Preserves fixes the above, but doubles
         // "overhead"
         // still pending on this.
     }

We've been having this debate over in the "[smart_ptr] Interest in the 
missing smart pointer (that can target the stack)" thread. It seems to 
have become a big thread, the relevant posts are near the bottom. I 
think we ultimately decided that both options should be provided. So for 
example safe<int> might have default initialization and almost_safe<int> 
might not. And even in the case where there is default initialization, 
there's the question of whether you should still require that the value 
be explicitly set before the first use. (This can be checked for and 
enforced in debug mode.)

While writing some security conscious applications I've been 
incidentally writing a small library of safer substitutes for some C++ 
data types (https://github.com/duneroadrunner/SaferCPlusPlus). Among the 
substitutes it includes are those for int and size_t. Rather than doing 
comprehensive range checking like your library does, my types just do 
range checking only where I have the feeling it's particularly important 
and worth the performance cost. That's basically just when converting to 
different integer types, and in operator-=() for size_t. Would your 
library support limiting it's range checks for performance reasons?

I guess the goal of my library is roughly to enable C++ programmers to, 
if they choose, write their code with "language safety" approaching that 
of Java's. But your library suggests that C++ could maybe even surpass 
Java as the choice for safe, secure and correct applications. So I 
wonder about the motivating cases for your library. I mean, was it 
designed to address specific use cases, or is it meant to be used more 
generally? I think your library is so novel to me, I don't have a good 
grasp on the range of application types that might end up using it. I 
might guess though, that some of the applications using your library to 
ensure against out of range arithmetic results might also benefit from 
using something like my library to ensure against, for example, invalid 
memory access or out of range vector element access.

I guess what I'm wondering is, whether you think your library is an 
intrinsically independent one addressing a specific domain, or 
ultimately should be part of a larger set of tools for facilitating 
safety/security/correctness in C++?

Noah