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-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 
yours.

> 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 
performance.)

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?