Re: [boost] updated version of safe integer library

Subject: Re: [boost] updated version of safe integer library
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-02-04 01:31:57

On 2/3/16 9:05 PM, Noah wrote:
> 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?

yep - you're assuming too much.

a) lot's of operations don't need checking:

int8_t i, j
i + j // can never overflow due to C++ type promotion rules
int l, m
l + m // can overflow.

But the later case can be "fixed" by changing the promotion policy
so that rather than int, the result is calculated in a larger 
intermediate type. etc. etc.  It turns out that many cases can't
fail anyway and others can be made safe with only minor changes.
This is why it's impossible to do without a type aware library
such as this one.

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

or maybe making a safe_pointer library.  Feel free to borrow anything
from the safe_integer library which might be useful.
>
> 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.)

OK - I can't really understand what your library does without
studying it.

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

Maybe, we'll see.  Maybe a few more big crashes might help.

> 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?

maybe - it wouldn't hurt

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

LOL - aren't we all.

Actually, I've worked on a fair number of embedded systems - which is my 
main inspiration for this.  In the real world, there is huge pressure to 
"make it work".  I get this.  Then it is "tested" until the bugs stop 
appearing.  It seems cost effective.  And perhaps it is. Because, to 
make a safe C++/C program now would require writing C code in the style 
of assembler, checking all intermediate operations and doing conversions 
by hand.  So the choice is pretty simple - ignore the issue or don't 
deliver the system.  The ultimate customer doesn't seem to care.  When 
the Mars Lander crashed into mars - wasting several hundred million 
dollars - due to a problem in conversion of english and metric units - 
an extensive investigation was undertaken.  The final result was ... it 
was nobody's fault.  To me this is incomprehensible.  It seems as as a 
facet of the "hacker mentality" which is widely lauded these days.  I 
think a big part of the problem is that I'm just to old and living in 
the distant past.

> 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?

I want to be able to write and read a program which clearly states what 
it is supposed to do and know that it will do exactly that or tell me 
why it can't do that.

What I don't want is to write/read a program that no one can understand 
what it does.  I don't want it to return an incorrect result at all.

among other things things that means.

a) if you write i + j you will get either the correct arithmetical 
result or some sort of exception that you are expected handle.

b) if you allocate an object ....

c) if you do anything at all - it either works as written or handles 
some sort of

d) if I write x + y (floating point) I get either the expected result or 
a reason why it can't be returned.  This is a very difficult goal to 
realize. Damian Vicino is working on this. I don't know his current 
progress.

I believe that C++ already addresses some of this- memory allocation, 
multi-threading, etc.  But other parts are only addressed in an ad hoc 
way - I want to see that changed.

Robert Ramey