Boost logo

Boost :

Subject: Re: [boost] updated version of safe integer library
From: Noah (duneroadrunner_at_[hidden])
Date: 2016-02-04 00:05:11

On 2/3/2016 3:18 PM, Robert Ramey wrote:

>> Would your library support limiting it's range checks for performance
>> reasons?
> I'm not sure what you mean here.

Sorry, I meant for cases where performance is more of a priority, can
people have range checking enabled for conversions, but disabled for
arithmetic operations (except for maybe operator-=() in the size_t
type). I assume that for arithmetic operations a lot of the range
checking would occur at run-time. I'm assuming?

>> 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,
> From what you've said, I think the libraries address the same problem.

Oh sorry, I wasn't clear. The main point of my library isn't the
replacements for integers. Probably the main element of my library is a
safe drop-in replacement for native pointers. And also an almost
completely safe implementation of std::vector and it's iterators. I was
thinking of dumping the integer classes from my library and just using

> But there is one more thing ...
> Writing correct code is not considered a major problem by most
> programmers and organizations which depend on code. Code that works
> most of the time is considered good enough. In spite of the current
> problems like unintended acceleration, failures on ABS systems, blown
> missile launches, crashing mars probes - this is not considered a
> problem. Two papers were submitted to CppCon 2015 on safe integers (one
> by me and one on bounded integers - similar topic) and neither were
> considered interesting to other reviewers to potential attendees. I
> suspect they are right - and that's a problem - a huge problem. This
> problem affects all computer languages. There has never been an
> industrial strength solution to this problem - until now. And the
> response has been .... I've requested twice that this library be added
> to the boost review queue - no action. I've requested twice that a
> simpler version of this library which was formulated as a proposal be
> added to the list of standard library proposals - again - no actions.
> It's just not important to most of the world. I'm not bitter (though it
> might seem that I am - I'm really not). I'm just disgusted. (which is
> an entirely different thing.

Amen brother :)

So maybe our libraries actually target slightly different domains. Your
library targets the "correctness" issue, where my library targets more
the "language safety" issue. Your library wants to make sure ABS systems
work reliably. My library is more targeted at reducing the incidence of
hackers taking over online banking servers (or your ip camera) through
web server vulnerabilities. (While, as much as possible, maintaining

You suggest, and you would know better than me, that your library has no
audience because people just don't care. But I wonder if it actually
would have an audience if there was more awareness. If it had better
marketing. I suspect that my library might also face an awareness issue
in that its natural customer is not currently a C++ programmer. Security
conscious applications often aren't written in C++ because of it's
reputation as an "unsafe" language. But if there were a "safe" C++
library, a single, standard, one-stop library for all your "safe" C++
needs, a library that was truly useful, that library might have a better
chance of achieving wider recognition. Don't you think?

I mean maybe in this case there's an intermediate step before becoming
part of boost. And that is becoming part of a proven, useful "safe" C++
library. "Correct" being a subcategory of "safe". Also, while the
performance cost may limit the (perceived) use cases for you library in
deployed applications, the performance cost may be less of an issue in
debug and test modes. So it might help if it was also marketed as a test
library. Just brainstorming here.

So I guess I'm wondering if you have any interest in general C++
language safety, or just in the correctness aspect. Or are you of the
position that C++ language safety, outside of correctness, is already a
solved issue?

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