Boost logo

Boost :

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
         // 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 ( 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++?


Boost list run by bdawes at, gregod at, cpdaniel at, john at