On 11/08/2012 03:59 AM, Ben Craig wrote:
> SafeInt information can be found here <http://safeint.codeplex.com/>.  Ba=
sically, it is an open source library authored by security expert David LeB=
lanc of Microsoft.  It is basically a "drop-in" replacement for integer typ=
es, and will throw an exception whenever integer overflows occur.  I believ=
e that getting this added to the standard would be a boon to C++ and secure=
 code.  It should be a relatively low effort addition considering the "proo=
f-of-concept" is already widely used within Microsoft.

Probably a good idea.

This would need a proposal, i.e. a paper essentially showing a bit of ratio=
nale
plus (eventually) the full text that would go into the standard.  Unless so=
meone
from the committee itself has enough interest to invest the substantial eff=
ort
to write that, it's not going to happen with a one-line post like this.

Or, you could write the proposal yourself and submit it (as a first start,
only show the motivation and rationale plus a rough outline; unless encoura=
ged
by WG21 to do the full thing, don't write the full standard text just yet;
it might turn out to be a waste of time).

Jens

--=20




.

On Sat, Nov 10, 2012 at 2:55 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
> On 11/08/2012 03:59 AM, Ben Craig wrote:
>> SafeInt information can be found here <http://safeint.codeplex.com/>.  B=
asically, it is an open source library authored by security expert David Le=
Blanc of Microsoft.  It is basically a "drop-in" replacement for integer ty=
pes, and will throw an exception whenever integer overflows occur.  I belie=
ve that getting this added to the standard would be a boon to C++ and secur=
e code.  It should be a relatively low effort addition considering the "pro=
of-of-concept" is already widely used within Microsoft.
>
> Probably a good idea.

Yes, although with no docs at the above link, and no examples in your
query, it is not possible to give a very complete answer.

> This would need a proposal, i.e. a paper essentially showing a bit of rat=
ionale
> plus (eventually) the full text that would go into the standard.  Unless =
someone
> from the committee itself has enough interest to invest the substantial e=
ffort
> to write that, it's not going to happen with a one-line post like this.
>
> Or, you could write the proposal yourself and submit it (as a first start=
,
> only show the motivation and rationale plus a rough outline; unless encou=
raged
> by WG21 to do the full thing, don't write the full standard text just yet=
;
> it might turn out to be a waste of time).

As Jens suggests, writing a query proposal is really the only way to
know how the LWG will react.

Since there are other "safe integer" libraries in use, a proposal
document should comment on the differences between the proposal and
other similar libraries. It always rattles me when a proposal appears
that doesn't seem to be aware of the work of others, and which
approaches were successful with users.

--Beman

--=20




.

------=_Part_739_23123215.1352633689285
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, November 8, 2012 3:59:50 AM UTC+1, Ben Craig wrote:
>
> SafeInt information can be found here <http://safeint.codeplex.com/>.
> Basically, it is an open source library authored by security expert David
> LeBlanc of Microsoft.  It is basically a "drop-in" replacement for integer
> types, and will throw an exception whenever integer overflows occur.  I
> believe that getting this added to the standard would be a boon to C++ and
> secure code.  It should be a relatively low effort addition considering the
> "proof-of-concept" is already widely used within Microsoft.
>

I don't think adding an isolated checked int makes much sense (I haven't
looked at SafeInt). I believe it would make more sense as part of a generic
integer type for which you can specify many overflow (and division by 0)
policies: undefined, wrap, saturate, set a flag, trap/throw, etc (we can
start with few policies).

--




------=_Part_739_23123215.1352633689285
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, November 8, 2012 3:59:50 AM UTC+1, Ben Craig wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">SafeInt information can be found <a href=
=3D"http://safeint.codeplex.com/" target=3D"_blank">here</a>.&nbsp; Basical=
ly, it is an open source library authored by security expert David LeBlanc =
of Microsoft.&nbsp; It is basically a "drop-in" replacement for integer typ=
es, and will throw an exception whenever integer overflows occur.&nbsp; I b=
elieve that getting this added to the standard would be a boon to C++ and s=
ecure code.&nbsp; It should be a relatively low effort addition considering=
 the "proof-of-concept" is already widely used within Microsoft.<br></block=
quote><div><br>I don't think adding an isolated checked int makes much sens=
e (I haven't looked at SafeInt). I believe it would make more sense as part=
 of a generic integer type for which you can specify many overflow (and div=
ision by 0) policies: undefined, wrap, saturate, set a flag, trap/throw, et=
c (we can start with few policies).<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_739_23123215.1352633689285--

.

------=_Part_402_8616947.1352663893296
Content-Type: text/plain; charset=ISO-8859-1

Yay for that. Currently, if you want to check for overflow and other
situations like that, you need to either write weird tests (result + b < a,
for example, huh) or rely on assembly (like `jc` on x86). Creating some
reasonable way to access such flag or throw something on carry, etc. would
be great.

Now (following x86 example), throwing on carry is trivial; just add `jc`
here and make it jump to throwing code. Accessing the flag would be
different, harder. It would either require construct similar to assembly
`jc` (if [[overflow]]? looks weird), or keeping additional flag for each
variable, which would kill the point of doing it without library construct
- for example, `std::safe<int>`.

Just throwing some thoughts.

On Sunday, 11 November 2012 12:34:49 UTC+1, Marc wrote:
>
> On Thursday, November 8, 2012 3:59:50 AM UTC+1, Ben Craig wrote:
>>
>> SafeInt information can be found here <http://safeint.codeplex.com/>.
>> Basically, it is an open source library authored by security expert David
>> LeBlanc of Microsoft.  It is basically a "drop-in" replacement for integer
>> types, and will throw an exception whenever integer overflows occur.  I
>> believe that getting this added to the standard would be a boon to C++ and
>> secure code.  It should be a relatively low effort addition considering the
>> "proof-of-concept" is already widely used within Microsoft.
>>
>
> I don't think adding an isolated checked int makes much sense (I haven't
> looked at SafeInt). I believe it would make more sense as part of a generic
> integer type for which you can specify many overflow (and division by 0)
> policies: undefined, wrap, saturate, set a flag, trap/throw, etc (we can
> start with few policies).
>

--




------=_Part_402_8616947.1352663893296
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yay for that. Currently, if you want to check for overflow and other situat=
ions like that, you need to either write weird tests (result + b &lt; a, fo=
r example, huh) or rely on assembly (like `jc` on x86). Creating some reaso=
nable way to access such flag or throw something on carry, etc. would be gr=
eat.<div><br></div><div>Now (following x86 example), throwing on carry is t=
rivial; just add `jc` here and make it jump to throwing code. Accessing the=
 flag would be different, harder. It would either require construct similar=
 to assembly `jc` (if [[overflow]]? looks weird), or keeping additional fla=
g for each variable, which would kill the point of doing it without library=
 construct - for example, `std::safe&lt;int&gt;`.</div><div><br></div><div>=
Just throwing some thoughts.<br><br>On Sunday, 11 November 2012 12:34:49 UT=
C+1, Marc  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, =
November 8, 2012 3:59:50 AM UTC+1, Ben Craig wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">SafeInt information can be found <a href=3D"http://safeint.=
codeplex.com/" target=3D"_blank">here</a>.&nbsp; Basically, it is an open s=
ource library authored by security expert David LeBlanc of Microsoft.&nbsp;=
 It is basically a "drop-in" replacement for integer types, and will throw =
an exception whenever integer overflows occur.&nbsp; I believe that getting=
 this added to the standard would be a boon to C++ and secure code.&nbsp; I=
t should be a relatively low effort addition considering the "proof-of-conc=
ept" is already widely used within Microsoft.<br></blockquote><div><br>I do=
n't think adding an isolated checked int makes much sense (I haven't looked=
 at SafeInt). I believe it would make more sense as part of a generic integ=
er type for which you can specify many overflow (and division by 0) policie=
s: undefined, wrap, saturate, set a flag, trap/throw, etc (we can start wit=
h few policies).<br></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_402_8616947.1352663893296--

.

------=_Part_87_26684902.1352838708507
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi - I was notified of this thread on Sunday, and am happy to answer=20
questions about my library.
=20
A few comments I can make on some of what is here so far:
=20
1) Rationale - integer checking is hard - much more difficult than it would=
=20
seem at first. Many people can't get the math right to start with, and then=
=20
get the checks wrong when they do try (e.g., if ( a * b < 0 ) for signed=20
multiplication). There are also very subtle problems involving code that=20
isn't quite standards-compliant (e.g., signed integer rollover). There's a=
=20
need for a library that can just be dropped into existing code which does=
=20
not change the current logic, and which will help solve this problem. The=
=20
SafeInt library works nicely to solve these issues, as well as difficult=20
things, like checking to see if a cast on entry into a function results in=
=20
information loss.
=20
2) I have not extensively reviewed other libraries. The one that I'm aware=
=20
of which came before my work (first released in 2005) was the Microsoft=20
IntSafe library. It is written in C, and is easy to use incorrectly.=20
SafeInt takes a more robust C++ approach. I believe other libraries have=20
been created after mine was released, and I'm largely aware of them=20
because John Regehr of the University of Utah did some nice work to find a=
=20
small number of flaws in SafeInt. His team looked at other libraries, and=
=20
found much more substantial flaws. I can take a look at the other=20
libraries, or it would really be better for an unbiased 3rd party to do the=
=20
comparison. Other than IntSafe, I am not aware of any libraries that=20
pre-dated SafeInt.
=20
3) There are two versions of SafeInt that are public - one ships in Visual=
=20
Studio, and is only expected to be correct with that compiler. The other is=
=20
at www.codeplex.com/SafeInt, should be thoroughly standards-compliant (if=
=20
not, let me know, I will consider it a bug and fix it), and is known to=20
work correctly with a number of compilers.
=20
4) Just checking the carry flag is insufficient. For example, adding 2=20
16-bit shorts into a 32-bit register will never trip the carry flag, but if=
=20
the result is assigned to a short, it may represent an overflow - ironic=20
that if sizeof(short) < sizeof(int), the signed short addition overflow is=
=20
defined by the standard (due to operator casting), but signed int overflow=
=20
is not - these are the sorts of oddities that make the problem so difficult=
=20
for most programmers.
=20
5) The library has had significant adoption within Microsoft, and has=20
proven very useful in mitigating this class of problem, which often=20
manifests as security bugs. It has been downloaded over 5000 times, but I'm=
=20
not aware of what other products it may have ended up in.
=20
I'll be happy to answer any questions and help with this process. If=20
there's significant interest, I can work with the Microsoft standards team=
=20
to do the full write-up needed. I've participated in other standards=20
bodies, but not this one.
=20
Thanks to all for the kind comments thus far -=20

On Sunday, November 11, 2012 11:58:13 AM UTC-8, Micha=C5=82 Dominiak wrote:

> Yay for that. Currently, if you want to check for overflow and other=20
> situations like that, you need to either write weird tests (result + b < =
a,=20
> for example, huh) or rely on assembly (like `jc` on x86). Creating some=
=20
> reasonable way to access such flag or throw something on carry, etc. woul=
d=20
> be great.
>
> Now (following x86 example), throwing on carry is trivial; just add `jc`=
=20
> here and make it jump to throwing code. Accessing the flag would be=20
> different, harder. It would either require construct similar to assembly=
=20
> `jc` (if [[overflow]]? looks weird), or keeping additional flag for each=
=20
> variable, which would kill the point of doing it without library construc=
t=20
> - for example, `std::safe<int>`.
>
> Just throwing some thoughts.
>
> On Sunday, 11 November 2012 12:34:49 UTC+1, Marc wrote:
>>
>> On Thursday, November 8, 2012 3:59:50 AM UTC+1, Ben Craig wrote:
>>>
>>> SafeInt information can be found here <http://safeint.codeplex.com/>. =
=20
>>> Basically, it is an open source library authored by security expert Dav=
id=20
>>> LeBlanc of Microsoft.  It is basically a "drop-in" replacement for inte=
ger=20
>>> types, and will throw an exception whenever integer overflows occur.  I=
=20
>>> believe that getting this added to the standard would be a boon to C++ =
and=20
>>> secure code.  It should be a relatively low effort addition considering=
 the=20
>>> "proof-of-concept" is already widely used within Microsoft.
>>>
>>
>> I don't think adding an isolated checked int makes much sense (I haven't=
=20
>> looked at SafeInt). I believe it would make more sense as part of a gene=
ric=20
>> integer type for which you can specify many overflow (and division by 0)=
=20
>> policies: undefined, wrap, saturate, set a flag, trap/throw, etc (we can=
=20
>> start with few policies).
>>
>

--=20




------=_Part_87_26684902.1352838708507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>Hi - I was notified of this thread on Sunday, and am happy to answer q=
uestions about my library.</div><div>&nbsp;</div><div>A few comments I can =
make on some of what is here so far:</div><div>&nbsp;</div><div>1) Rational=
e - integer checking is hard - much more difficult than it would seem at fi=
rst. Many people can't get the math right to start with, and then get the c=
hecks wrong when they do try (e.g., if ( a * b &lt; 0 ) for signed multipli=
cation). There are also very subtle problems involving code that isn't quit=
e standards-compliant (e.g., signed integer rollover). There's a need for a=
 library that can just be dropped into existing code which does not change =
the current logic, and which will help solve this problem. The SafeInt libr=
ary works nicely to solve these issues, as well as difficult things, like c=
hecking to see if a cast on entry into a function results in information lo=
ss.</div><div>&nbsp;</div><div>2) I have not extensively reviewed other lib=
raries. The one that I'm aware of which came before my work (first released=
 in 2005) was the Microsoft IntSafe library. It is written in C, and is eas=
y to use incorrectly. SafeInt takes a more robust C++ approach. I believe o=
ther libraries have been created after mine was released, and I'm largely a=
ware of them because&nbsp;John Regehr of the University of Utah did some ni=
ce work to find a small number of flaws in SafeInt. His team&nbsp;looked at=
 other libraries, and found much more substantial flaws. I can take a look =
at the other libraries, or it would really be better for an unbiased 3rd pa=
rty to do the comparison. Other than IntSafe, I am not aware of any librari=
es that pre-dated SafeInt.</div><div>&nbsp;</div><div>3) There are two vers=
ions of SafeInt that are public - one ships in Visual Studio, and is only e=
xpected to be correct with that compiler. The other is at <a href=3D"http:/=
/www.codeplex.com/SafeInt">www.codeplex.com/SafeInt</a>, should be thorough=
ly standards-compliant (if not, let me know, I will consider it a bug and f=
ix it), and is known to work correctly with a number of compilers.</div><di=
v>&nbsp;</div><div>4) Just checking the carry flag is insufficient. For exa=
mple, adding 2 16-bit&nbsp;shorts into a 32-bit register will never trip th=
e carry flag, but if the result is assigned to a short, it may represent an=
 overflow - ironic that if sizeof(short) &lt; sizeof(int), the signed short=
 addition overflow is defined by the standard (due to operator casting), bu=
t signed int overflow is not - these are the sorts of oddities that make th=
e problem so difficult for most programmers.</div><div>&nbsp;</div><div>5) =
The library has had significant adoption within Microsoft, and has proven v=
ery useful in mitigating this class of problem, which often manifests as se=
curity bugs. It has been downloaded over 5000 times, but I'm not aware of w=
hat other products it may have ended up in.</div><div>&nbsp;</div><div>I'll=
 be happy to answer any questions and help with this process. If there's si=
gnificant interest, I can work with the Microsoft standards team to do the =
full write-up needed. I've participated in other standards bodies, but not =
this one.</div><div>&nbsp;</div><div>Thanks to all for the kind comments th=
us far - </div><div><br>On Sunday, November 11, 2012 11:58:13 AM UTC-8, Mic=
ha=C5=82 Dominiak wrote:</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204=
, 204); border-left-width: 1px; border-left-style: solid;">Yay for that. Cu=
rrently, if you want to check for overflow and other situations like that, =
you need to either write weird tests (result + b &lt; a, for example, huh) =
or rely on assembly (like `jc` on x86). Creating some reasonable way to acc=
ess such flag or throw something on carry, etc. would be great.<div><br></d=
iv><div>Now (following x86 example), throwing on carry is trivial; just add=
 `jc` here and make it jump to throwing code. Accessing the flag would be d=
ifferent, harder. It would either require construct similar to assembly `jc=
` (if [[overflow]]? looks weird), or keeping additional flag for each varia=
ble, which would kill the point of doing it without library construct - for=
 example, `std::safe&lt;int&gt;`.</div><div><br></div><div>Just throwing so=
me thoughts.<br><br>On Sunday, 11 November 2012 12:34:49 UTC+1, Marc  wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;">On Thursday, November 8, 2012 3:59:50 AM UTC+=
1, Ben Craig wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">SafeInt information can be =
found <a href=3D"http://safeint.codeplex.com/" target=3D"_blank">here</a>.&=
nbsp; Basically, it is an open source library authored by security expert D=
avid LeBlanc of Microsoft.&nbsp; It is basically a "drop-in" replacement fo=
r integer types, and will throw an exception whenever integer overflows occ=
ur.&nbsp; I believe that getting this added to the standard would be a boon=
 to C++ and secure code.&nbsp; It should be a relatively low effort additio=
n considering the "proof-of-concept" is already widely used within Microsof=
t.<br></blockquote><div><br>I don't think adding an isolated checked int ma=
kes much sense (I haven't looked at SafeInt). I believe it would make more =
sense as part of a generic integer type for which you can specify many over=
flow (and division by 0) policies: undefined, wrap, saturate, set a flag, t=
rap/throw, etc (we can start with few policies).<br></div></blockquote></di=
v></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_87_26684902.1352838708507--

.

On Tue, Nov 13, 2012 at 3:31 PM,  <dvd_leblanc@yahoo.com> wrote:
> Hi - I was notified of this thread on Sunday, and am happy to answer
> questions about my library.
>
> A few comments I can make on some of what is here so far:
>
> 1) Rationale - integer checking is hard - much more difficult than it would
> seem at first. Many people can't get the math right to start with, and then
> get the checks wrong when they do try (e.g., if ( a * b < 0 ) for signed
> multiplication). There are also very subtle problems involving code that
> isn't quite standards-compliant (e.g., signed integer rollover). There's a
> need for a library that can just be dropped into existing code which does
> not change the current logic, and which will help solve this problem. The
> SafeInt library works nicely to solve these issues, as well as difficult
> things, like checking to see if a cast on entry into a function results in
> information loss.
>
> 2) I have not extensively reviewed other libraries. The one that I'm aware
> of which came before my work (first released in 2005) was the Microsoft
> IntSafe library. It is written in C, and is easy to use incorrectly. SafeInt
> takes a more robust C++ approach. I believe other libraries have been
> created after mine was released, and I'm largely aware of them because John
> Regehr of the University of Utah did some nice work to find a small number
> of flaws in SafeInt. His team looked at other libraries, and found much more
> substantial flaws. I can take a look at the other libraries, or it would
> really be better for an unbiased 3rd party to do the comparison. Other than
> IntSafe, I am not aware of any libraries that pre-dated SafeInt.
>
> 3) There are two versions of SafeInt that are public - one ships in Visual
> Studio, and is only expected to be correct with that compiler. The other is
> at www.codeplex.com/SafeInt, should be thoroughly standards-compliant (if
> not, let me know, I will consider it a bug and fix it), and is known to work
> correctly with a number of compilers.
>
> 4) Just checking the carry flag is insufficient. For example, adding 2
> 16-bit shorts into a 32-bit register will never trip the carry flag, but if
> the result is assigned to a short, it may represent an overflow - ironic
> that if sizeof(short) < sizeof(int), the signed short addition overflow is
> defined by the standard (due to operator casting), but signed int overflow
> is not - these are the sorts of oddities that make the problem so difficult
> for most programmers.
>
> 5) The library has had significant adoption within Microsoft, and has proven
> very useful in mitigating this class of problem, which often manifests as
> security bugs. It has been downloaded over 5000 times, but I'm not aware of
> what other products it may have ended up in.
>
> I'll be happy to answer any questions and help with this process. If there's
> significant interest, I can work with the Microsoft standards team to do the
> full write-up needed. I've participated in other standards bodies, but not
> this one.

Sounds like an excellent candidate for standardization. Please do
consider making a formal proposal. Stephan T. Lavavej (aka STL) is the
Microsoft person you probably want to talk to about getting together a
formal proposal.

--Beman

--




.

------=_Part_1053_13973459.1353551132738
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, November 7, 2012 6:59:50 PM UTC-8, Ben Craig wrote:
>
> SafeInt information can be found here <http://safeint.codeplex.com/>.  ...
>

I also found myself interested in this code.  When I got around to looking
at it I felt it could be improved.  Being a "booster" I wanted to leverage
on Boost stuff to make a simpler implementation.  The result of my efforts
can be found at http://rrsd.com/blincubator.com/bi_library/safe-numerics/

Main differences are:
a) follows Boost/C++ library conventions as to naming, formating etc.
b) Is many many lines shorter due to the usage of more meta-programming
technique in the implementation.
c) Includes an exhaustive set of tests including all combinations of corner
cases - generated with boost pre-processor library.
d) defines concepts for "numeric" types and includes concept checking via
the boost concept checking library.
e) includes documentation more in line with currently recommended "formal"
style.

Robert Ramey

--




------=_Part_1053_13973459.1353551132738
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, November 7, 2012 6:59:50 PM UTC-8, Ben Craig wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">SafeInt information can be found=
 <a href=3D"http://safeint.codeplex.com/" target=3D"_blank">here</a>.&nbsp;=
 ...<br></blockquote><div><br>I also found myself interested in this code.&=
nbsp; When I got around to looking at it I felt it could be improved.&nbsp;=
 Being a "booster" I wanted to leverage on Boost stuff to make a simpler im=
plementation.&nbsp; The result of my efforts can be found at http://rrsd.co=
m/blincubator.com/bi_library/safe-numerics/<br><br>Main differences are:<br=
>a) follows Boost/C++ library conventions as to naming, formating etc.<br>b=
) Is many many lines shorter due to the usage of more meta-programming tech=
nique in the implementation.<br>c) Includes an exhaustive set of tests incl=
uding all combinations of corner cases - generated with boost pre-processor=
 library.<br>d) defines concepts for "numeric" types and includes concept c=
hecking via the boost concept checking library.<br>e) includes documentatio=
n more in line with currently recommended "formal" style.<br><br>Robert Ram=
ey<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1053_13973459.1353551132738--

.

--e89a8f923f3acd9c8d04cf15ae99
Content-Type: text/plain; charset=ISO-8859-1

I would most definitely like to have a standardized interface to handle
numerical overflow.

I do however have some reservations on doing it by means of an integer
wrapper.

First, I think we need such "safe numeric operations" to handle floating
point values just as well. While the mechanisms are different, the
requirements are exactly the same (and floating-point does overflow no
matter how big their range is). In fact, I think we need it for arbitrary
numeric types, including rationals, complex, user-defined extended
precision, interval, etc... (and consistently defined for even unlimited
precision numeric types, even if the overflow test always yields false)

Second, I wonder if a wrapper is the best interface. Since this is a
"security" utility, it needs to be consistently applied *all over* the
relevant source code, otherwise it is not really effective
A lot, if not most, critical and complex numeric code (where this is mostly
needed) depends on third-party libraries, and in the numerical community
there is a huge base of reusable code that is (yet) not sufficiently
generic to let you get away with simple using a wrapper type at the highest
level.
In other words, you might use SafeInt in your own code but it is not easy
to have third-party code use it as well.

Since the overflow is always a side effect of operations, and operations
are expressed in C++ via operators (and functions), I wonder if the library
shouldn't be in a form of "safe operators and functions" as opposed to
"safe numeric type".

IIUC, the current operator overloading mechanism should allow something
like the following:

#include <safe_numeric_operations>

// This "activates" the overflow detection on any supported type, including
builtin types
using std::safe_numeric_operations ;

void test()
{
  try
  {
     int a = std::numeric_limits<int>::max();

     // std::safe_numeric_operations::operator + (int,int) being called here
     int r = a + a ;
  }
  catch ( std::bad_numeric_conversion ) { }
}




On Wed, Nov 21, 2012 at 11:25 PM, <robertmacleranramey@gmail.com> wrote:

>
>
> On Wednesday, November 7, 2012 6:59:50 PM UTC-8, Ben Craig wrote:
>>
>> SafeInt information can be found here <http://safeint.codeplex.com/>.
>> ...
>>
>
> I also found myself interested in this code.  When I got around to looking
> at it I felt it could be improved.  Being a "booster" I wanted to leverage
> on Boost stuff to make a simpler implementation.  The result of my efforts
> can be found at http://rrsd.com/blincubator.com/bi_library/safe-numerics/
>
> Main differences are:
> a) follows Boost/C++ library conventions as to naming, formating etc.
> b) Is many many lines shorter due to the usage of more meta-programming
> technique in the implementation.
> c) Includes an exhaustive set of tests including all combinations of
> corner cases - generated with boost pre-processor library.
> d) defines concepts for "numeric" types and includes concept checking via
> the boost concept checking library.
> e) includes documentation more in line with currently recommended "formal"
> style.
>
> Robert Ramey
>
>  --
>
>
>
>



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--e89a8f923f3acd9c8d04cf15ae99
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would most definitely like to have a standardized interface to handle num=
erical overflow.<br><br>I do however have some reservations on doing it by =
means of an integer wrapper.<br><br>First, I think we need such &quot;safe =
numeric operations&quot; to handle floating point values just as well. Whil=
e the mechanisms are different, the requirements are exactly the same (and =
floating-point does overflow no matter how big their range is). In fact, I =
think we need it for arbitrary numeric types, including rationals, complex,=
 user-defined extended precision, interval, etc... (and consistently define=
d for even unlimited precision numeric types, even if the overflow test alw=
ays yields false)<br>

<br>Second, I wonder if a wrapper is the best interface. Since this is a &q=
uot;security&quot; utility, it needs to be consistently applied *all over* =
the relevant source code, otherwise it is not really effective<br>A lot, if=
 not most, critical and complex numeric code (where this is mostly needed) =
depends on third-party libraries, and in the numerical community there is a=
 huge base of reusable code that is (yet) not sufficiently generic to let y=
ou get away with simple using a wrapper type at the highest level. <br>

In other words, you might use SafeInt in your own code but it is not easy t=
o have third-party code use it as well.<br><br>Since the overflow is always=
 a side effect of operations, and operations are expressed in C++ via opera=
tors (and functions), I wonder if the library shouldn&#39;t be in a form of=
 &quot;safe operators and functions&quot; as opposed to &quot;safe numeric =
type&quot;.<br>

<br>IIUC, the current operator overloading mechanism should allow something=
 like the following:<br><br>#include &lt;safe_numeric_operations&gt;<br><br=
>// This &quot;activates&quot; the overflow detection on any supported type=
, including builtin types<br>

using std::safe_numeric_operations ;<br><br>void test()<br>{<br>=A0 try<br>=
=A0 {<br>=A0=A0=A0=A0 int a =3D std::numeric_limits&lt;int&gt;::max();<br><=
br>=A0=A0=A0=A0 // std::safe_numeric_operations::operator + (int,int) being=
 called here<br>=A0=A0=A0=A0 int r =3D a + a ;<br>

=A0 }<br>=A0 catch ( std::bad_numeric_conversion ) { }<br>}<br><br><br><div=
 class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Nov 21, 2=
012 at 11:25 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:robertmacleranram=
ey@gmail.com" target=3D"_blank">robertmacleranramey@gmail.com</a>&gt;</span=
> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>On Wednesday, November 7, 2012 6:59:=
50 PM UTC-8, Ben Craig wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

SafeInt information can be found <a href=3D"http://safeint.codeplex.com/" t=
arget=3D"_blank">here</a>.=A0 ...<br></blockquote><div><br>I also found mys=
elf interested in this code.=A0 When I got around to looking at it I felt i=
t could be improved.=A0 Being a &quot;booster&quot; I wanted to leverage on=
 Boost stuff to make a simpler implementation.=A0 The result of my efforts =
can be found at <a href=3D"http://rrsd.com/blincubator.com/bi_library/safe-=
numerics/" target=3D"_blank">http://rrsd.com/blincubator.com/bi_library/saf=
e-numerics/</a><br>

<br>Main differences are:<br>a) follows Boost/C++ library conventions as to=
 naming, formating etc.<br>b) Is many many lines shorter due to the usage o=
f more meta-programming technique in the implementation.<br>c) Includes an =
exhaustive set of tests including all combinations of corner cases - genera=
ted with boost pre-processor library.<br>

d) defines concepts for &quot;numeric&quot; types and includes concept chec=
king via the boost concept checking library.<br>e) includes documentation m=
ore in line with currently recommended &quot;formal&quot; style.<br><br>

Robert Ramey<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></font><=
/span></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
=A0<br>
=A0<br>
=A0<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Fernando =
Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-co=
nsulting.com">http://www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f923f3acd9c8d04cf15ae99--

.

------=_Part_751_10102874.1353599922560
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, November 22, 2012 5:45:42 AM UTC-8, Fernando Cacciola wrote:
>
> I would most definitely like to have a standardized interface to handle
> numerical overflow.
>
> I do however have some reservations on doing it by means of an integer
> wrapper.
>
> First, I think we need such "safe numeric operations" to handle floating
> point values just as well. While the mechanisms are different, the
> requirements are exactly the same (and floating-point does overflow no
> matter how big their range is). In fact, I think we need it for arbitrary
> numeric types, including rationals, complex, user-defined extended
> precision, interval, etc... (and consistently defined for even unlimited
> precision numeric types, even if the overflow test always yields false)
>
> Second, I wonder if a wrapper is the best interface. Since this is a
> "security" utility, it needs to be consistently applied *all over* the
> relevant source code, otherwise it is not really effective
>

Don't forget the essential C++ maxim: pay only for what you use.

There is a lot of code that's just fine with non-secure integers. They no
need to have overflow checks and such every time time they loop from 0 to
240. They aren't going to overflow their loop counter. There are many such
occurrences in a code-base where the structure and nature of the code means
that overflow is just not a realistic possibility.

This means that whatever we adopt has to be an opt-in mechanism, not an
opt-out.


> A lot, if not most, critical and complex numeric code (where this is
> mostly needed) depends on third-party libraries, and in the numerical
> community there is a huge base of reusable code that is (yet) not
> sufficiently generic to let you get away with simple using a wrapper type
> at the highest level.
> In other words, you might use SafeInt in your own code but it is not easy
> to have third-party code use it as well.
>
> Since the overflow is always a side effect of operations, and operations
> are expressed in C++ via operators (and functions), I wonder if the library
> shouldn't be in a form of "safe operators and functions" as opposed to
> "safe numeric type".


> IIUC, the current operator overloading mechanism should allow something
> like the following:
>
> #include <safe_numeric_operations>
>
> // This "activates" the overflow detection on any supported type,
> including builtin types
> using std::safe_numeric_operations ;
>
> void test()
> {
>   try
>   {
>      int a = std::numeric_limits<int>::max();
>
>      // std::safe_numeric_operations::operator + (int,int) being called
> here
>      int r = a + a ;
>   }
>   catch ( std::bad_numeric_conversion ) { }
> }
>

Ignoring the fact that a recompile would suddenly cause massive amounts of
code to potentially throw std::bad_numeric_conversion without the knowledge
of that code's owners (ie: we can't do that), there's also the practical
issue that this won't magically affect any *C* code that people often use.

But even more importantly, I'm pretty sure you can't overload
operator+(int, int). Besides being practically infeasible by creating the
possibility of exceptions in potentially exception-unsafe code, it's simply
not possible.


>
>
>
>
> On Wed, Nov 21, 2012 at 11:25 PM, <robertmac...@gmail.com <javascript:>>wrote:
>
>>
>>
>> On Wednesday, November 7, 2012 6:59:50 PM UTC-8, Ben Craig wrote:
>>>
>>> SafeInt information can be found here <http://safeint.codeplex.com/>.
>>> ...
>>>
>>
>> I also found myself interested in this code.  When I got around to
>> looking at it I felt it could be improved.  Being a "booster" I wanted to
>> leverage on Boost stuff to make a simpler implementation.  The result of my
>> efforts can be found at
>> http://rrsd.com/blincubator.com/bi_library/safe-numerics/
>>
>> Main differences are:
>> a) follows Boost/C++ library conventions as to naming, formating etc.
>> b) Is many many lines shorter due to the usage of more meta-programming
>> technique in the implementation.
>> c) Includes an exhaustive set of tests including all combinations of
>> corner cases - generated with boost pre-processor library.
>> d) defines concepts for "numeric" types and includes concept checking via
>> the boost concept checking library.
>> e) includes documentation more in line with currently recommended
>> "formal" style.
>>
>> Robert Ramey
>>
>>  --
>>
>>
>>
>>
>
>
>
> --
> Fernando Cacciola
> SciSoft Consulting, Founder
> http://www.scisoft-consulting.com
>

--




------=_Part_751_10102874.1353599922560
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, November 22, 2012 5:45:42 AM UTC-8, Fernando Cacciola =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">I would most definitely =
like to have a standardized interface to handle numerical overflow.<br><br>=
I do however have some reservations on doing it by means of an integer wrap=
per.<br><br>First, I think we need such "safe numeric operations" to handle=
 floating point values just as well. While the mechanisms are different, th=
e requirements are exactly the same (and floating-point does overflow no ma=
tter how big their range is). In fact, I think we need it for arbitrary num=
eric types, including rationals, complex, user-defined extended precision, =
interval, etc... (and consistently defined for even unlimited precision num=
eric types, even if the overflow test always yields false)<br>

<br>Second, I wonder if a wrapper is the best interface. Since this is a "s=
ecurity" utility, it needs to be consistently applied *all over* the releva=
nt source code, otherwise it is not really effective<br></blockquote><div><=
br>Don't forget the essential C++ maxim: pay only for what you use.<br><br>=
There is a lot of code that's just fine with non-secure integers. They no n=
eed to have overflow checks and such every time time they loop from 0 to 24=
0. They aren't going to overflow their loop counter. There are many such oc=
currences in a code-base where the structure and nature of the code means t=
hat overflow is just not a realistic possibility.<br><br>This means that wh=
atever we adopt has to be an opt-in mechanism, not an opt-out.<br>&nbsp;</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">A lot, if not most, critica=
l and complex numeric code (where this is mostly needed) depends on third-p=
arty libraries, and in the numerical community there is a huge base of reus=
able code that is (yet) not sufficiently generic to let you get away with s=
imple using a wrapper type at the highest level. <br>

In other words, you might use SafeInt in your own code but it is not easy t=
o have third-party code use it as well.<br><br>Since the overflow is always=
 a side effect of operations, and operations are expressed in C++ via opera=
tors (and functions), I wonder if the library shouldn't be in a form of "sa=
fe operators and functions" as opposed to "safe numeric type".&nbsp;</block=
quote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">

<br>IIUC, the current operator overloading mechanism should allow something=
 like the following:<br><br>#include &lt;safe_numeric_operations&gt;<br><br=
>// This "activates" the overflow detection on any supported type, includin=
g builtin types<br>

using std::safe_numeric_operations ;<br><br>void test()<br>{<br>&nbsp; try<=
br>&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp; int a =3D std::numeric_limits&lt;in=
t&gt;::max(<wbr>);<br><br>&nbsp;&nbsp;&nbsp;&nbsp; // std::safe_numeric_ope=
rations::<wbr>operator + (int,int) being called here<br>&nbsp;&nbsp;&nbsp;&=
nbsp; int r =3D a + a ;<br>

&nbsp; }<br>&nbsp; catch ( std::bad_numeric_conversion ) { }<br>}<br></bloc=
kquote><div><br>Ignoring the fact that a recompile would suddenly cause mas=
sive amounts of code to potentially throw std::bad_numeric_conversion witho=
ut the knowledge of that code's owners (ie: we can't do that), there's also=
 the practical issue that this won't magically affect any <i>C</i> code tha=
t people often use.<br><br>But even more importantly, I'm pretty sure you c=
an't overload operator+(int, int). Besides being practically infeasible by =
creating the possibility of exceptions in potentially exception-unsafe code=
, it's simply not possible.<br>&nbsp;</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><br><br><div><br><br><div class=3D"gmail_quote">On Wed, Nov 21=
, 2012 at 11:25 PM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"LXTDalCMlzUJ">robertmac...@gmail.com</=
a><wbr>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>On Wednesday, November 7, 2012 6:59:=
50 PM UTC-8, Ben Craig wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

SafeInt information can be found <a href=3D"http://safeint.codeplex.com/" t=
arget=3D"_blank">here</a>.&nbsp; ...<br></blockquote><div><br>I also found =
myself interested in this code.&nbsp; When I got around to looking at it I =
felt it could be improved.&nbsp; Being a "booster" I wanted to leverage on =
Boost stuff to make a simpler implementation.&nbsp; The result of my effort=
s can be found at <a href=3D"http://rrsd.com/blincubator.com/bi_library/saf=
e-numerics/" target=3D"_blank">http://rrsd.com/blincubator.<wbr>com/bi_libr=
ary/safe-numerics/</a><br>

<br>Main differences are:<br>a) follows Boost/C++ library conventions as to=
 naming, formating etc.<br>b) Is many many lines shorter due to the usage o=
f more meta-programming technique in the implementation.<br>c) Includes an =
exhaustive set of tests including all combinations of corner cases - genera=
ted with boost pre-processor library.<br>

d) defines concepts for "numeric" types and includes concept checking via t=
he boost concept checking library.<br>e) includes documentation more in lin=
e with currently recommended "formal" style.<br><br>

Robert Ramey<span><font color=3D"#888888"><br><br></font></span></div><span=
><font color=3D"#888888">

<p></p>

-- <br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Fernando =
Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-co=
nsulting.com" target=3D"_blank">http://www.scisoft-consulting.<wbr>com</a><=
br>
</div>
</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_751_10102874.1353599922560--

.

------=_Part_1508_24734082.1353602126226
Content-Type: text/plain; charset=ISO-8859-1

I would like to have a standard that deals with overflows. I think the best
way would be an arbitrary precision class used for internal linkage and the
right cast functions to create object with external linkage. I think
dynamic_cast could in theory be used to throw on overflow. I would also
like a saturate_cast which would convert to the nearest valid value of the
output type. The class definition could also look like this:

template<int64_t MIN, int64_t MAX> //minimum and maximum runtime value that
can be stored
class integer
{
    /*Large enough storage type for MIN and MAX*/ value;
    public:
    template<int64_t OMIN, int64_t OMAX>
    integer<MIN+OMIN, MAX+OMAX> operator+(integer<OMIN,OMAX> i) const;
};

Now, there is a limit to how much precision the MIN and MAX could have. So
it would still be interesting to have a safeintmax_t and safeuintmax_t.

Other options that could be interesting:

A third template parameter being a common divisor. If you make an integer
from a long*, the alignment can guaranty a minimum common divisor among all
results.

An arbitrary precision floating point class which knows its min and max to
some extent.

A cast that lowers precision so all preceding operations could be replaced
by less precise and faster operations.

--




------=_Part_1508_24734082.1353602126226
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would like to have a standard that deals with overflows. I think the best=
 way would be an arbitrary precision class used for internal linkage and th=
e right cast functions to create object with external linkage. I think dyna=
mic_cast could in theory be used to throw on overflow. I would also like a =
saturate_cast which would convert to the nearest valid value of the output =
type. The class definition could also look like this:<br><br><span style=3D=
"font-family: courier new,monospace;">template&lt;int64_t MIN, int64_t MAX&=
gt; //minimum and maximum runtime value that can be stored<br>class integer=
<br>{<br>&nbsp;&nbsp;&nbsp; /*Large enough storage type for MIN and MAX*/ v=
alue;<br>&nbsp;&nbsp;&nbsp; public:<br>&nbsp;&nbsp;&nbsp; template&lt;int64=
_t OMIN, int64_t OMAX&gt;<br>&nbsp;&nbsp;&nbsp; integer&lt;MIN+OMIN, MAX+OM=
AX&gt; operator+(integer&lt;OMIN,OMAX&gt; i) const;<br>};<br></span><br>Now=
, there is a limit to how much precision the MIN and MAX could have. So it =
would still be interesting to have a safeintmax_t and safeuintmax_t.<br><br=
>Other options that could be interesting:<br><br>A third template parameter=
 being a common divisor. If you make an integer from a long*, the alignment=
 can guaranty a minimum common divisor among all results.<br><br>An arbitra=
ry precision floating point class which knows its min and max to some exten=
t.<br><br>A cast that lowers precision so all preceding operations could be=
 replaced by less precise and faster operations.<br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1508_24734082.1353602126226--

.

------=_Part_181_13275302.1353602308824
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, November 22, 2012 5:45:42 AM UTC-8, Fernando Cacciola wrote:
>
> I would most definitely like to have a standardized interface to handle
> numerical overflow.
>
> I do however have some reservations on doing it by means of an integer
> wrapper.
>
> First, I think we need such "safe numeric operations" to handle floating
> point values just as well. While the mechanisms are different, the
> requirements are exactly the same (and floating-point does overflow no
> matter how big their range is). In fact, I think we need it for arbitrary
> numeric types, including rationals, complex, user-defined extended
> precision, interval, etc... (and consistently defined for even unlimited
> precision numeric types, even if the overflow test always yields false)
>

Note that my proposed implementation defines a concept "Numeric" for all
types which look like a number and are supported via std::limits. I've
implemented this for safe<int>, safe<unsigned int>, etc..  All of the other
types listed above would fit into this scheme.  (Though implementing this
for floating point types would be an effort).

>
> Second, I wonder if a wrapper is the best interface. Since this is a
> "security" utility, it needs to be consistently applied *all over* the
> relevant source code, otherwise it is not really effective
>

I totally disagree with this.  I must be optional on the part of the user.
we can't really know that the user really want's to do.  Maybe he's just
fine with high order bits being lost. So if you applied this "everywhere"
you'd have to supply an "escape hatch" which would complicate it's usage.
Further more, some users would want to use this only for debug build and
perhaps define away the functionality for release builds.  Finally,  using
it "everywhere" would mean mucking with C++ language - a language which is
already to complex for anyone to write a correct compiler for.


> A lot, if not most, critical and complex numeric code (where this is
> mostly needed) depends on third-party libraries, and in the numerical
> community there is a huge base of reusable code that is (yet) not
> sufficiently generic to let you get away with simple using a wrapper type
> at the highest level.
> In other words, you might use SafeInt in your own code but it is not easy
> to have third-party code use it as well.
>

Which is as it must be.  We can't fix the whole world - only our own code.
But this shouldn't prevent us from doing that.


> IIUC, the current operator overloading mechanism should allow something
> like the following:
>
> #include <safe_numeric_operations>
>
> // This "activates" the overflow detection on any supported type,
> including builtin types
> using std::safe_numeric_operations ;
>
> void test()
> {
>   try
>   {
>      int a = std::numeric_limits<int>::max();
>
>      // std::safe_numeric_operations::operator + (int,int) being called
> here
>      int r = a + a ;
>   }
>   catch ( std::bad_numeric_conversion ) { }
> }
>
> This is pretty much exactly what my reference implementation does!

Robert Ramey

--




------=_Part_181_13275302.1353602308824
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, November 22, 2012 5:45:42 AM UTC-8, Fernando Cacciola =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">I would most definitely =
like to have a standardized interface to handle numerical overflow.<br><br>=
I do however have some reservations on doing it by means of an integer wrap=
per.<br><br>First, I think we need such "safe numeric operations" to handle=
 floating point values just as well. While the mechanisms are different, th=
e requirements are exactly the same (and floating-point does overflow no ma=
tter how big their range is). In fact, I think we need it for arbitrary num=
eric types, including rationals, complex, user-defined extended precision, =
interval, etc... (and consistently defined for even unlimited precision num=
eric types, even if the overflow test always yields false)<br></blockquote>=
<div><br>Note that my proposed implementation defines a concept "Numeric" f=
or all types which look like a number and are supported via std::limits. I'=
ve implemented this for safe&lt;int&gt;, safe&lt;unsigned int&gt;, etc..&nb=
sp; All of the other types listed above would fit into this scheme.&nbsp; (=
Though implementing this for floating point types would be an effort). <br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">

<br>Second, I wonder if a wrapper is the best interface. Since this is a "s=
ecurity" utility, it needs to be consistently applied *all over* the releva=
nt source code, otherwise it is not really effective<br></blockquote><div><=
br>I totally disagree with this.&nbsp; I must be optional on the part of th=
e user.&nbsp; we can't really know that the user really want's to do.&nbsp;=
 Maybe he's just fine with high order bits being lost. So if you applied th=
is "everywhere" you'd have to supply an "escape hatch" which would complica=
te it's usage.&nbsp; Further more, some users would want to use this only f=
or debug build and perhaps define away the functionality for release builds=
..&nbsp; Finally,&nbsp; using it "everywhere" would mean mucking with C++ la=
nguage - a language which is already to complex for anyone to write a corre=
ct compiler for.<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">A lot, if not most, critical and complex numeric code (where this is =
mostly needed) depends on third-party libraries, and in the numerical commu=
nity there is a huge base of reusable code that is (yet) not sufficiently g=
eneric to let you get away with simple using a wrapper type at the highest =
level. <br>

In other words, you might use SafeInt in your own code but it is not easy t=
o have third-party code use it as well.<br></blockquote><div><br>Which is a=
s it must be.&nbsp; We can't fix the whole world - only our own code. But t=
his shouldn't prevent us from doing that.<br>&nbsp;<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">IIUC, the current operator overloading mecha=
nism should allow something like the following:<br><br>#include &lt;safe_nu=
meric_operations&gt;<br><br>// This "activates" the overflow detection on a=
ny supported type, including builtin types<br>

using std::safe_numeric_operations ;<br><br>void test()<br>{<br>&nbsp; try<=
br>&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp; int a =3D std::numeric_limits&lt;in=
t&gt;::max(<wbr>);<br><br>&nbsp;&nbsp;&nbsp;&nbsp; // std::safe_numeric_ope=
rations::<wbr>operator + (int,int) being called here<br>&nbsp;&nbsp;&nbsp;&=
nbsp; int r =3D a + a ;<br>

&nbsp; }<br>&nbsp; catch ( std::bad_numeric_conversion ) { }<br>}<br><br></=
blockquote><div>This is pretty much exactly what my reference implementatio=
n does! <br><br>Robert Ramey<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_181_13275302.1353602308824--

.

------=_Part_1666_31160683.1353602835085
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, November 22, 2012 8:35:26 AM UTC-8, Marc Thibault wrote:

>
> template<int64_t MIN, int64_t MAX> //minimum and maximum runtime value
> that can be stored
>

....

Note that my reference implementation includes safe_signed_range<min, max>
and safe_unsigned_range<min, max>.  In fact, safe<int> .. are implemented
in terms of these more general templates.  - something like

template<T>
struct safe_unsigned_int<T> : public safe_range<std::limits<T>::min ...
{};

So you get this functionality for free.


Robert Ramey

--




------=_Part_1666_31160683.1353602835085
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, November 22, 2012 8:35:26 AM UTC-8, Marc Thibault wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><span style=3D"font-=
family:courier new,monospace">template&lt;int64_t MIN, int64_t MAX&gt; //mi=
nimum and maximum runtime value that can be stored<br></span></blockquote><=
div><br>...<br><br>Note that my reference implementation includes safe_sign=
ed_range&lt;min, max&gt; and safe_unsigned_range&lt;min, max&gt;.&nbsp; In =
fact, safe&lt;int&gt; .. are implemented in terms of these more general tem=
plates.&nbsp; - something like<br><br>template&lt;T&gt;<br>struct safe_unsi=
gned_int&lt;T&gt; : public safe_range&lt;std::limits&lt;T&gt;::min ...<br>{=
};<br><br>So you get this functionality for free.<br><br><br>Robert Ramey<b=
r></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1666_31160683.1353602835085--

.

--14dae9340d5d42d36c04cf186f46
Content-Type: text/plain; charset=ISO-8859-1

OK, I agree with your observations about silently overloading operators.

OTOH, I still think there is something to be considered in the fact that it
is the operations that overflow (and other unwanted side effects), not the
numbers themselves, so I would propose a layer of overloaded functions,
that can be applied on any type, including built-in types, and on top of
that a higher-level wrapper (or wrappers like in Robert's library)

The advantage of doing so, following your own observations, is that in most
numeric code, you don't really need to check for all operations, so a
performance critical algorithm might not be able to just use the wrapper as
a drop-in replacement for int, yet it could be made secure by adding
checked operations where specifically necessary.

Having said all that, I would like to at least mention the fact that there
is a largest picture to consider here, where integer overflow is just one
case. I'm referring to the domain of numerical robustness in general, and
while a comprehensive work on that is way out of the scope of a relatively
simple proposal like this one, the big picture should still be constantly
present and considered.

From the more general point of view of numerical robustness, throwing an
exception when a numerical computation could not be performed (such as in
the case of integer overflow) is the most basic building block, but it is
still too low-level. There is a lot of work in the research community about
how to truly handle numerical limitations, as opposed to not handling in
order (which is what a safe-int does). Unfortunately, most of that work is
specific to an application domain and a given numeric type or types, so
it's hard to extrapolate general idioms and utilities. However, there are
two basic elements that are usually found in most of them:

First there is the general mechanism of using a proper type to perform an
operation. For intance, an int64 to operate two int32. This is the
mechanism used by SafeInt and Robert's code, but it's actually used in a
lot of places dealing with integer numerics. So, we should standardized
that, such that it is generally available to any programmer to do something
like:

auto r = (secure)a + b;

here (secure) would bootstrap an operator+ which selects the proper return
type to guarantee the addition does not overflow (or you could just have
secure_add(a,b) or whatever)

Second, there is the general requirement to test whether the result of
operations are reliable, beyond just overflow.
One idiom that has emerged in recent years and which I found intuitive
enough to be general is the concept of "certified arithmetic" (usually
implemented with interval floating-point numbers). The idea is that, on the
one hand, the result of operations carry a certificate (explicit or not) to
indicate if it succeeded or not, and on the other hand, triboolean logic is
used along, made general and easy.  In terms of safe_int this would mean
that instead of throwing, the result is just flaged as overflow, much like
a floating-point saturates to +- INF, but, when you try to compare, the
answer is "maybe" (and if you want to convert it to plain int it throws)

The general form of the idiom would be something like this:

auto e = ( a  + b == c + d ) ;
if ( certainy(e) )
{
}
else if ( certainly_not(e ) )
{
}
else
{
  // can't tell. It not possible to compare the numbers
}

Here, if a,b,c,d are integers numbers, and either of the additions
overflow, the code flows to the last else, and without even any exception
being thrown.
The trick is that operator == returns a tribool (or it's generalization
uncertain<bool>)


Best


On Thu, Nov 22, 2012 at 1:58 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Thursday, November 22, 2012 5:45:42 AM UTC-8, Fernando Cacciola wrote:
>>
>> I would most definitely like to have a standardized interface to handle
>> numerical overflow.
>>
>> I do however have some reservations on doing it by means of an integer
>> wrapper.
>>
>> First, I think we need such "safe numeric operations" to handle floating
>> point values just as well. While the mechanisms are different, the
>> requirements are exactly the same (and floating-point does overflow no
>> matter how big their range is). In fact, I think we need it for arbitrary
>> numeric types, including rationals, complex, user-defined extended
>> precision, interval, etc... (and consistently defined for even unlimited
>> precision numeric types, even if the overflow test always yields false)
>>
>> Second, I wonder if a wrapper is the best interface. Since this is a
>> "security" utility, it needs to be consistently applied *all over* the
>> relevant source code, otherwise it is not really effective
>>
>
> Don't forget the essential C++ maxim: pay only for what you use.
>
> There is a lot of code that's just fine with non-secure integers. They no
> need to have overflow checks and such every time time they loop from 0 to
> 240. They aren't going to overflow their loop counter. There are many such
> occurrences in a code-base where the structure and nature of the code means
> that overflow is just not a realistic possibility.
>
> This means that whatever we adopt has to be an opt-in mechanism, not an
> opt-out.
>
>
>> A lot, if not most, critical and complex numeric code (where this is
>> mostly needed) depends on third-party libraries, and in the numerical
>> community there is a huge base of reusable code that is (yet) not
>> sufficiently generic to let you get away with simple using a wrapper type
>> at the highest level.
>> In other words, you might use SafeInt in your own code but it is not easy
>> to have third-party code use it as well.
>>
>> Since the overflow is always a side effect of operations, and operations
>> are expressed in C++ via operators (and functions), I wonder if the library
>> shouldn't be in a form of "safe operators and functions" as opposed to
>> "safe numeric type".
>
>
>> IIUC, the current operator overloading mechanism should allow something
>> like the following:
>>
>> #include <safe_numeric_operations>
>>
>> // This "activates" the overflow detection on any supported type,
>> including builtin types
>> using std::safe_numeric_operations ;
>>
>> void test()
>> {
>>   try
>>   {
>>      int a = std::numeric_limits<int>::max(**);
>>
>>      // std::safe_numeric_operations::**operator + (int,int) being
>> called here
>>      int r = a + a ;
>>   }
>>   catch ( std::bad_numeric_conversion ) { }
>> }
>>
>
> Ignoring the fact that a recompile would suddenly cause massive amounts of
> code to potentially throw std::bad_numeric_conversion without the knowledge
> of that code's owners (ie: we can't do that), there's also the practical
> issue that this won't magically affect any *C* code that people often use.
>
> But even more importantly, I'm pretty sure you can't overload
> operator+(int, int). Besides being practically infeasible by creating the
> possibility of exceptions in potentially exception-unsafe code, it's simply
> not possible.
>
>
>>
>>
>>
>>
>> On Wed, Nov 21, 2012 at 11:25 PM, <robertmac...@gmail.com**> wrote:
>>
>>>
>>>
>>> On Wednesday, November 7, 2012 6:59:50 PM UTC-8, Ben Craig wrote:
>>>>
>>>> SafeInt information can be found here <http://safeint.codeplex.com/>.
>>>> ...
>>>>
>>>
>>> I also found myself interested in this code.  When I got around to
>>> looking at it I felt it could be improved.  Being a "booster" I wanted to
>>> leverage on Boost stuff to make a simpler implementation.  The result of my
>>> efforts can be found at http://rrsd.com/blincubator.**
>>> com/bi_library/safe-numerics/<http://rrsd.com/blincubator.com/bi_library/safe-numerics/>
>>>
>>> Main differences are:
>>> a) follows Boost/C++ library conventions as to naming, formating etc.
>>> b) Is many many lines shorter due to the usage of more meta-programming
>>> technique in the implementation.
>>> c) Includes an exhaustive set of tests including all combinations of
>>> corner cases - generated with boost pre-processor library.
>>> d) defines concepts for "numeric" types and includes concept checking
>>> via the boost concept checking library.
>>> e) includes documentation more in line with currently recommended
>>> "formal" style.
>>>
>>> Robert Ramey
>>>
>>>  --
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Fernando Cacciola
>> SciSoft Consulting, Founder
>> http://www.scisoft-consulting.**com <http://www.scisoft-consulting.com>
>>
>  --
>
>
>
>



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--14dae9340d5d42d36c04cf186f46
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

OK, I agree with your observations about silently overloading operators.<br=
><br>OTOH, I still think there is something to be considered in the fact th=
at it is the operations that overflow (and other unwanted side effects), no=
t the numbers themselves, so I would propose a layer of overloaded function=
s, that can be applied on any type, including built-in types, and on top of=
 that a higher-level wrapper (or wrappers like in Robert&#39;s library)<br>

<br>The advantage of doing so, following your own observations, is that in =
most numeric code, you don&#39;t really need to check for all operations, s=
o a performance critical algorithm might not be able to just use the wrappe=
r as a drop-in replacement for int, yet it could be made secure by adding c=
hecked operations where specifically necessary.<br>

<br>Having said all that, I would like to at least mention the fact that th=
ere is a largest picture to consider here, where integer overflow is just o=
ne case. I&#39;m referring to the domain of numerical robustness in general=
, and while a comprehensive work on that is way out of the scope of a relat=
ively simple proposal like this one, the big picture should still be consta=
ntly present and considered.<br>

<br>From the more general point of view of numerical robustness, throwing a=
n exception when a numerical computation could not be performed (such as in=
 the case of integer overflow) is the most basic building block, but it is =
still too low-level. There is a lot of work in the research community about=
 how to truly handle numerical limitations, as opposed to not handling in o=
rder (which is what a safe-int does). Unfortunately, most of that work is s=
pecific to an application domain and a given numeric type or types, so it&#=
39;s hard to extrapolate general idioms and utilities. However, there are t=
wo basic elements that are usually found in most of them:<br>

<br>First there is the general mechanism of using a proper type to perform =
an operation. For intance, an int64 to operate two int32. This is the mecha=
nism used by SafeInt and Robert&#39;s code, but it&#39;s actually used in a=
 lot of places dealing with integer numerics. So, we should standardized th=
at, such that it is generally available to any programmer to do something l=
ike:<br>

<br>auto r =3D (secure)a + b;<br><br>here (secure) would bootstrap an opera=
tor+ which selects the proper return type to guarantee the addition does no=
t overflow (or you could just have secure_add(a,b) or whatever)<br><br>Seco=
nd, there is the general requirement to test whether the result of operatio=
ns are reliable, beyond just overflow. <br>

One idiom that has emerged in recent years and which I found intuitive enou=
gh to be general is the concept of &quot;certified arithmetic&quot; (usuall=
y implemented with interval floating-point numbers). The idea is that, on t=
he one hand, the result of operations carry a certificate (explicit or not)=
 to indicate if it succeeded or not, and on the other hand, triboolean logi=
c is used along, made general and easy.=A0 In terms of safe_int this would =
mean that instead of throwing, the result is just flaged as overflow, much =
like a floating-point saturates to +- INF, but, when you try to compare, th=
e answer is &quot;maybe&quot; (and if you want to convert it to plain int i=
t throws)<br>

<br>The general form of the idiom would be something like this:<br><br>auto=
 e =3D ( a=A0 + b =3D=3D c + d ) ;<br>if ( certainy(e) )<br>{<br>}<br>else =
if ( certainly_not(e ) )<br>{<br>}<br>else<br>{<br>=A0 // can&#39;t tell. I=
t not possible to compare the numbers<br>

}<br><br>Here, if a,b,c,d are integers numbers, and either of the additions=
 overflow, the code flows to the last else, and without even any exception =
being thrown.<br>The trick is that operator =3D=3D returns a tribool (or it=
&#39;s generalization uncertain&lt;bool&gt;)<br>

<br><br>Best<br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Thu, Nov 22, 2012 at 1:58 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>=
&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br><br>On Thursday, Novem=
ber 22, 2012 5:45:42 AM UTC-8, Fernando Cacciola wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

I would most definitely like to have a standardized interface to handle num=
erical overflow.<br><br>I do however have some reservations on doing it by =
means of an integer wrapper.<br><br>First, I think we need such &quot;safe =
numeric operations&quot; to handle floating point values just as well. Whil=
e the mechanisms are different, the requirements are exactly the same (and =
floating-point does overflow no matter how big their range is). In fact, I =
think we need it for arbitrary numeric types, including rationals, complex,=
 user-defined extended precision, interval, etc... (and consistently define=
d for even unlimited precision numeric types, even if the overflow test alw=
ays yields false)<br>



<br>Second, I wonder if a wrapper is the best interface. Since this is a &q=
uot;security&quot; utility, it needs to be consistently applied *all over* =
the relevant source code, otherwise it is not really effective<br></blockqu=
ote>

</div><div><br>Don&#39;t forget the essential C++ maxim: pay only for what =
you use.<br><br>There is a lot of code that&#39;s just fine with non-secure=
 integers. They no need to have overflow checks and such every time time th=
ey loop from 0 to 240. They aren&#39;t going to overflow their loop counter=
.. There are many such occurrences in a code-base where the structure and na=
ture of the code means that overflow is just not a realistic possibility.<b=
r>

<br>This means that whatever we adopt has to be an opt-in mechanism, not an=
 opt-out.<br>=A0</div><div class=3D"im"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">

A lot, if not most, critical and complex numeric code (where this is mostly=
 needed) depends on third-party libraries, and in the numerical community t=
here is a huge base of reusable code that is (yet) not sufficiently generic=
 to let you get away with simple using a wrapper type at the highest level.=
 <br>



In other words, you might use SafeInt in your own code but it is not easy t=
o have third-party code use it as well.<br><br>Since the overflow is always=
 a side effect of operations, and operations are expressed in C++ via opera=
tors (and functions), I wonder if the library shouldn&#39;t be in a form of=
 &quot;safe operators and functions&quot; as opposed to &quot;safe numeric =
type&quot;.=A0</blockquote>

<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">

<br>IIUC, the current operator overloading mechanism should allow something=
 like the following:<br><br>#include &lt;safe_numeric_operations&gt;<br><br=
>// This &quot;activates&quot; the overflow detection on any supported type=
, including builtin types<br>



using std::safe_numeric_operations ;<br><br>void test()<br>{<br>=A0 try<br>=
=A0 {<br>=A0=A0=A0=A0 int a =3D std::numeric_limits&lt;int&gt;::max(<u></u>=
);<br><br>=A0=A0=A0=A0 // std::safe_numeric_operations::<u></u>operator + (=
int,int) being called here<br>

=A0=A0=A0=A0 int r =3D a + a ;<br>

=A0 }<br>=A0 catch ( std::bad_numeric_conversion ) { }<br>}<br></blockquote=
></div><div><br>Ignoring the fact that a recompile would suddenly cause mas=
sive amounts of code to potentially throw std::bad_numeric_conversion witho=
ut the knowledge of that code&#39;s owners (ie: we can&#39;t do that), ther=
e&#39;s also the practical issue that this won&#39;t magically affect any <=
i>C</i> code that people often use.<br>

<br>But even more importantly, I&#39;m pretty sure you can&#39;t overload o=
perator+(int, int). Besides being practically infeasible by creating the po=
ssibility of exceptions in potentially exception-unsafe code, it&#39;s simp=
ly not possible.<br>

=A0</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>=
<div><br><br><div class=3D"gmail_quote">On Wed, Nov 21, 2012 at 11:25 PM,  =
<span dir=3D"ltr">&lt;<a>robertmac...@gmail.com</a><u></u>&gt;</span> wrote=
:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>On Wednesday, November 7, 2012 6:59:=
50 PM UTC-8, Ben Craig wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">



SafeInt information can be found <a href=3D"http://safeint.codeplex.com/" t=
arget=3D"_blank">here</a>.=A0 ...<br></blockquote><div><br>I also found mys=
elf interested in this code.=A0 When I got around to looking at it I felt i=
t could be improved.=A0 Being a &quot;booster&quot; I wanted to leverage on=
 Boost stuff to make a simpler implementation.=A0 The result of my efforts =
can be found at <a href=3D"http://rrsd.com/blincubator.com/bi_library/safe-=
numerics/" target=3D"_blank">http://rrsd.com/blincubator.<u></u>com/bi_libr=
ary/safe-numerics/</a><br>



<br>Main differences are:<br>a) follows Boost/C++ library conventions as to=
 naming, formating etc.<br>b) Is many many lines shorter due to the usage o=
f more meta-programming technique in the implementation.<br>c) Includes an =
exhaustive set of tests including all combinations of corner cases - genera=
ted with boost pre-processor library.<br>



d) defines concepts for &quot;numeric&quot; types and includes concept chec=
king via the boost concept checking library.<br>e) includes documentation m=
ore in line with currently recommended &quot;formal&quot; style.<br><br>



Robert Ramey<span><font color=3D"#888888"><br><br></font></span></div><span=
><font color=3D"#888888">

<p></p>

-- <br>
=A0<br>
=A0<br>
=A0<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Fernando =
Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-co=
nsulting.com" target=3D"_blank">http://www.scisoft-consulting.<u></u>com</a=
><br>


</div>
</blockquote>

<p></p></div>

-- <br>
=A0<br>
=A0<br>
=A0<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>Sc=
iSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">=
http://www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--14dae9340d5d42d36c04cf186f46--

.

------=_Part_475_27452044.1353617845943
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, November 22, 2012 9:02:42 AM UTC-8, Fernando Cacciola wrote:
>
> OK, I agree with your observations about silently overloading operators.
>
> OTOH, ....


Well one can make this very elaborate.  When I was doing this I
experimented with keep track of number of bits a compile time so that
operations which could never overthrow would generate no runtime overhead.
There are lots of things one could do along this line - especially now that
we have something like auto.

But in the end, I decided to keep it as simple as I could. The whole
library can be summarized in one sentence.

"any operation involving a safe numeric type will produce the expected
mathematical result or throw an exception"

Making it do more or less than this would severely hamper it's utility.

Robert Ramey



--




------=_Part_475_27452044.1353617845943
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, November 22, 2012 9:02:42 AM UTC-8, Fernando Cacciola =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">OK, I agree with your ob=
servations about silently overloading operators.<br><br>OTOH, ....</blockqu=
ote><div><br>Well one can make this very elaborate.&nbsp; When I was doing =
this I experimented with keep track of number of bits a compile time so tha=
t operations which could never overthrow would generate no runtime overhead=
..&nbsp; There are lots of things one could do along this line - especially =
now that we have something like auto.<br><br>But in the end, I decided to k=
eep it as simple as I could. The whole library can be summarized in one sen=
tence.<br><br>"any operation involving a safe numeric type will produce the=
 expected mathematical result or throw an exception"<br><br>Making it do mo=
re or less than this would severely hamper it's utility.<br><br>Robert Rame=
y<br><br>&nbsp;<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_475_27452044.1353617845943--

.

--047d7b3436a21a239504cf1c3896
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 22, 2012 at 5:57 PM, <robertmacleranramey@gmail.com> wrote:

>
>
> On Thursday, November 22, 2012 9:02:42 AM UTC-8, Fernando Cacciola wrote:
>
>> OK, I agree with your observations about silently overloading operators.
>>
>> OTOH, ....
>
>
> Well one can make this very elaborate.  When I was doing this I
> experimented with keep track of number of bits a compile time so that
> operations which could never overthrow would generate no runtime overhead.
> There are lots of things one could do along this line - especially now that
> we have something like auto.
>
> But in the end, I decided to keep it as simple as I could. The whole
> library can be summarized in one sentence.
>
> "any operation involving a safe numeric type will produce the expected
> mathematical result or throw an exception"
>
> Making it do more or less than this would severely hamper it's utility.
>
>

I didn't intend to suggest that a library should do less or more than
proposed here. I suggested that in order to prepare and evaluate such a
proposal, the bigger picture should be taken into account.

For instance, both SafeInt's and your code *requires* a primitive operation
that returns the result in a larger type such that it is known not to
overflow. The overflow detection is just an extra step, and it's only
required because (or rather IFF) the result is needed to be converted into
the same type as the operands. That means that both libraries under
consideration are really the composition of two layers: the bottom layer
that performs the operation in a way that it's result is known to be
correct, and the layer that performs the conversion to a given receiving
type but doing a proper range check first.

Then I'm saying that, since the bottom layer is a requirement for these
libraries, and it's also useful--and used--in several other numerical
techniques, it should be standardized as such (and not hidden as an
implementation detail as it proposed)

Furthermore, with such a decomposition in place, the top layer can be
*totally* given by a general numeric_cast<> utility, such as the the one
proposed in n1879
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1879.htm)

But that's not all.

I'm also saying that the bigger picture could critically affect design
decision even within the scope proposed. I gave the example of certified
arithmetic because that would suggest that a given safe_int should not
necessarily just throw right up front, but it could instead flag the
overflow and throw only when necessary, such as when casting to int. This
is important because if you are going to compare the overflowed result, you
can just return "maybe" from the comparison without throwing an exception.
This not only allows the client code to be *elegantly* explicit about the
way overflowed results affect the computation results, but it also allows
the library to be used in contexts where exceptions are to be avoided when
possible.


Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b3436a21a239504cf1c3896
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Thu, Nov 22, 2012 =
at 5:57 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:robertmacleranramey@gm=
ail.com" target=3D"_blank">robertmacleranramey@gmail.com</a>&gt;</span> wro=
te:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im"><br><br=
>On Thursday, November 22, 2012 9:02:42 AM UTC-8, Fernando Cacciola wrote:<=
/div>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im">OK, I a=
gree with your observations about silently overloading operators.<br><br></=
div>

OTOH, ....</blockquote><div><br>Well one can make this very elaborate.=A0 W=
hen I was doing this I experimented with keep track of number of bits a com=
pile time so that operations which could never overthrow would generate no =
runtime overhead.=A0 There are lots of things one could do along this line =
- especially now that we have something like auto.<br>

<br>But in the end, I decided to keep it as simple as I could. The whole li=
brary can be summarized in one sentence.<br><br>&quot;any operation involvi=
ng a safe numeric type will produce the expected mathematical result or thr=
ow an exception&quot;<br>

<br>Making it do more or less than this would severely hamper it&#39;s util=
ity.<br><br></div></blockquote><div>=A0</div><div><span class=3D""><font co=
lor=3D"#888888">=A0<br>
</font></span></div></div>I didn&#39;t intend to suggest that a library sho=
uld do less or more than proposed here. I suggested that in order to prepar=
e and evaluate such a proposal, the bigger picture should be taken into acc=
ount.<br>

<br>For instance, both SafeInt&#39;s and your code *requires* a primitive o=
peration that returns the result in a larger type such that it is known not=
 to overflow. The overflow detection is just an extra step, and it&#39;s on=
ly required because (or rather IFF) the result is needed to be converted in=
to the same type as the operands. That means that both libraries under cons=
ideration are really the composition of two layers: the bottom layer that p=
erforms the operation in a way that it&#39;s result is known to be correct,=
 and the layer that performs the conversion to a given receiving type but d=
oing a proper range check first.<br>

<br>Then I&#39;m saying that, since the bottom layer is a requirement for t=
hese libraries, and it&#39;s also useful--and used--in several other numeri=
cal techniques, it should be standardized as such (and not hidden as an imp=
lementation detail as it proposed)<br>

<br>Furthermore, with such a decomposition in place, the top layer can be *=
totally* given by a general numeric_cast&lt;&gt; utility, such as the the o=
ne proposed in n1879<br> (<a href=3D"http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2005/n1879.htm">http://www.open-std.org/jtc1/sc22/wg21/docs/pa=
pers/2005/n1879.htm</a>)<br>

<br>But that&#39;s not all.<br><br>I&#39;m also saying that the bigger pict=
ure could critically affect design decision even within the scope proposed.=
 I gave the example of certified arithmetic because that would suggest that=
 a given safe_int should not necessarily just throw right up front, but it =
could instead flag the overflow and throw only when necessary, such as when=
 casting to int. This is important because if you are going to compare the =
overflowed result, you can just return &quot;maybe&quot; from the compariso=
n without throwing an exception. This not only allows the client code to be=
 *elegantly* explicit about the way overflowed results affect the computati=
on results, but it also allows the library to be used in contexts where exc=
eptions are to be avoided when possible.<br>

<br><br>Best<br>=A0<br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Foun=
der<br><a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-con=
sulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3436a21a239504cf1c3896--

.

------=_Part_1788_3158546.1353623101480
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, November 22, 2012 1:33:38 PM UTC-8, Fernando Cacciola wrote:
>
> On Thu, Nov 22, 2012 at 5:57 PM, <robertmac...@gmail.com <javascript:>>wrote:
>
>>
>>
>> On Thursday, November 22, 2012 9:02:42 AM UTC-8, Fernando Cacciola wrote:
>>
>>> OK, I agree with your observations about silently overloading operators.
>>>
>>> OTOH, ....
>>
>>
>> Well one can make this very elaborate.  When I was doing this I
>> experimented with keep track of number of bits a compile time so that
>> operations which could never overthrow would generate no runtime overhead.
>> There are lots of things one could do along this line - especially now that
>> we have something like auto.
>>
>> But in the end, I decided to keep it as simple as I could. The whole
>> library can be summarized in one sentence.
>>
>> "any operation involving a safe numeric type will produce the expected
>> mathematical result or throw an exception"
>>
>> Making it do more or less than this would severely hamper it's utility.
>>
>>
>
> I didn't intend to suggest that a library should do less or more than
> proposed here. I suggested that in order to prepare and evaluate such a
> proposal, the bigger picture should be taken into account.
>
> For instance, both SafeInt's and your code *requires* a primitive
> operation that returns the result in a larger type such that it is known
> not to overflow.
>

I don't think that's true.  That's not part of the interface or type
requirements. It's merely an implementation feature of the library because
it's the fastest way to do this.  It still checks for overflows on int64
operations even though there is not int 128 type - it has to use a much
slower method.



> The overflow detection is just an extra step, and it's only required
> because (or rather IFF) the result is needed to be converted into the same
> type as the operands.
>

The result is calculated to whatever precision is required to avoid
overflow. When the result is assigned somewhere - then the overflow is
caught.  So

safe<int16> a, b;
safe<int16> x = a + b; // could trap on overflow - but
safe<int32> x = a + b; // would never trap

An interesting side issue of this is that there is no run time overhead on
the second
statement because template meta programming is used to determine that
there can never, ever be an overflow. Finally

auto x = a + b; will result in x being of type safe<int32> and will never,
ever trap( actually I have to double check this).

So to my mind this is exactly what is desired.

That means that both libraries under consideration are really the
> composition of two layers: the bottom layer that performs the operation in
> a way that it's result is known to be correct, and the layer that performs
> the conversion to a given receiving type but doing a proper range check
> first.
>

In my implementation, the two layers are there - but can't be separated.
The "lower" layer happens on the + operator while the "upper" layer happens
on the = operator.  There is only one library though.

Then I'm saying that, since the bottom layer is a requirement for these
libraries, and it's also useful--and used--in several other numerical
techniques, it should be standardized as such (and not hidden as an
implementation detail as it proposed)

I'm guessing that anyone wanting to do this could just overload the =
operator. or use safe<?> as a constructor argument to his own special type.

But that's not all.

I'm also saying that the bigger picture could critically affect design
decision even within the scope proposed. I gave the example of certified
arithmetic because that would suggest that a given safe_int should not
necessarily just throw right up front, but it could instead flag the
overflow and throw only when necessary, such as when casting to int. This
is important because if you are going to compare the overflowed result, you
can just return "maybe" from the comparison without throwing an exception.
This not only allows the client code to be *elegantly* explicit about the
way overflowed results affect the computation results, but it also allows
the library to be used in contexts where exceptions are to be avoided when
possible.

as a practical matter, I don't see how you can "throw upfront" until you
actually do an assignment or explicit cast.  Take the following assignment.

safe<int16> a;
safe<int32> b;

auto x = a + b;  // what is the type of x?
auto x = b + a;  // is the type of y the same as the type of x?

Questions like these made me decide to divide the task as you suggested
a) do the calculation resulting in a type which can hold the true result
b) on assignment or cast (safe_cast ...) trap the attempt to save a value
which loses information.

Robert Ramey




--




------=_Part_1788_3158546.1353623101480
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, November 22, 2012 1:33:38 PM UTC-8, Fernando Cacciola =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div class=3D"gmail=
_quote">On Thu, Nov 22, 2012 at 5:57 PM,  <span dir=3D"ltr">&lt;<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"c-d6g_YCWMwJ">rober=
tmac...@gmail.com</a><wbr>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><br>On Thursday,=
 November 22, 2012 9:02:42 AM UTC-8, Fernando Cacciola wrote:</div>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div>OK, I agree with you=
r observations about silently overloading operators.<br><br></div>

OTOH, ....</blockquote><div><br>Well one can make this very elaborate.&nbsp=
; When I was doing this I experimented with keep track of number of bits a =
compile time so that operations which could never overthrow would generate =
no runtime overhead.&nbsp; There are lots of things one could do along this=
 line - especially now that we have something like auto.<br>

<br>But in the end, I decided to keep it as simple as I could. The whole li=
brary can be summarized in one sentence.<br><br>"any operation involving a =
safe numeric type will produce the expected mathematical result or throw an=
 exception"<br>

<br>Making it do more or less than this would severely hamper it's utility.=
<br><br></div></blockquote><div>&nbsp;</div><div><span><font color=3D"#8888=
88">&nbsp;<br>
</font></span></div></div>I didn't intend to suggest that a library should =
do less or more than proposed here. I suggested that in order to prepare an=
d evaluate such a proposal, the bigger picture should be taken into account=
..<br>

<br>For instance, both SafeInt's and your code *requires* a primitive opera=
tion that returns the result in a larger type such that it is known not to =
overflow. </div></blockquote><div><br>I don't think that's true.&nbsp; That=
's not part of the interface or type requirements. It's merely an implement=
ation feature of the library because it's the fastest way to do this.&nbsp;=
 It still checks for overflows on int64 operations even though there is not=
 int 128 type - it has to use a much slower method.<br><br>&nbsp;</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div>The overflow detection is jus=
t an extra step, and it's only required because (or rather IFF) the result =
is needed to be converted into the same type as the operands. </div></block=
quote><div><br>The result is calculated to whatever precision is required t=
o avoid overflow. When the result is assigned somewhere - then the overflow=
 is caught.&nbsp; So <br><br>safe&lt;int16&gt; a, b;<br>safe&lt;int16&gt; x=
 =3D a + b; // could trap on overflow - but<br>safe&lt;int32&gt; x =3D a + =
b; // would never trap<br><br>An interesting side issue of this is that the=
re is no run time overhead on the second<br>statement because template meta=
 programming is used to determine that<br>there can never, ever be an overf=
low. Finally<br><br>auto x =3D a + b; will result in x being of type safe&l=
t;int32&gt; and will never, ever trap( actually I have to double check this=
).<br><br>So to my mind this is exactly what is desired.<br></div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>That means that bot=
h libraries under consideration are really the composition of two layers: t=
he bottom layer that performs the operation in a way that it's result is kn=
own to be correct, and the layer that performs the conversion to a given re=
ceiving type but doing a proper range check first.<br></div></blockquote><d=
iv><br>In my implementation, the two layers are there - but can't be separa=
ted.&nbsp; The "lower" layer happens on the + operator while the "upper" la=
yer happens on the =3D operator.&nbsp; There is only one library though.<br=
>&nbsp;<br>Then I'm saying that, since the bottom layer is a requirement fo=
r these libraries, and it's also useful--and used--in several other numeric=
al techniques, it should be standardized as such (and not hidden as an impl=
ementation detail as it proposed)<br><br>I'm guessing that anyone wanting t=
o do this could just overload the =3D operator. or use safe&lt;?&gt; as a c=
onstructor argument to his own special type.<br>

<br>But that's not all.<br><br>I'm also saying that the bigger picture coul=
d critically affect design decision even within the scope proposed. I gave =
the example of certified arithmetic because that would suggest that a given=
 safe_int should not necessarily just throw right up front, but it could in=
stead flag the overflow and throw only when necessary, such as when casting=
 to int. This is important because if you are going to compare the overflow=
ed result, you can just return "maybe" from the comparison without throwing=
 an exception. This not only allows the client code to be *elegantly* expli=
cit about the way overflowed results affect the computation results, but it=
 also allows the library to be used in contexts where exceptions are to be =
avoided when possible.<br><br>as a practical matter, I don't see how you ca=
n "throw upfront" until you actually do an assignment or explicit cast.&nbs=
p; Take the following assignment.<br><br>safe&lt;int16&gt; a;<br>safe&lt;in=
t32&gt; b;<br><br>auto x =3D a + b;&nbsp; // what is the type of x?<br>auto=
 x =3D b + a;&nbsp; // is the type of y the same as the type of x?<br><br>Q=
uestions like these made me decide to divide the task as you suggested<br>a=
) do the calculation resulting in a type which can hold the true result<br>=
b) on assignment or cast (safe_cast ...) trap the attempt to save a value w=
hich loses information.<br><br>Robert Ramey<br><br><br>
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1788_3158546.1353623101480--

.

--047d7b3436a2f517a604cf1d51f5
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 22, 2012 at 7:25 PM, <robertmacleranramey@gmail.com> wrote:

>
>
> On Thursday, November 22, 2012 1:33:38 PM UTC-8, Fernando Cacciola wrote:
>
>> On Thu, Nov 22, 2012 at 5:57 PM, <robertmac...@gmail.com**> wrote:
>>
>>>
>>>
>>> On Thursday, November 22, 2012 9:02:42 AM UTC-8, Fernando Cacciola wrote:
>>>
>>>> OK, I agree with your observations about silently overloading operators.
>>>>
>>>> OTOH, ....
>>>
>>>
>>> Well one can make this very elaborate.  When I was doing this I
>>> experimented with keep track of number of bits a compile time so that
>>> operations which could never overthrow would generate no runtime overhead.
>>> There are lots of things one could do along this line - especially now that
>>> we have something like auto.
>>>
>>> But in the end, I decided to keep it as simple as I could. The whole
>>> library can be summarized in one sentence.
>>>
>>> "any operation involving a safe numeric type will produce the expected
>>> mathematical result or throw an exception"
>>>
>>> Making it do more or less than this would severely hamper it's utility.
>>>
>>>
>>
>> I didn't intend to suggest that a library should do less or more than
>> proposed here. I suggested that in order to prepare and evaluate such a
>> proposal, the bigger picture should be taken into account.
>>
>> For instance, both SafeInt's and your code *requires* a primitive
>> operation that returns the result in a larger type such that it is known
>> not to overflow.
>>
>
> I don't think that's true.  That's not part of the interface or type
> requirements. It's merely an implementation feature of the library because
> it's the fastest way to do this.  It still checks for overflows on int64
> operations even though there is not int 128 type - it has to use a much
> slower method.
>
> I haven't checked your code in this corner case, but SafeInt uses a form
of 128 bits type (when configured as such)

Since it is always true that the result of an integer operation between two
N bits integer fits perfectly in a 2*N bits integer, it is entirely
possible to generalize the pattern even for 64bits by providing a
library-based 128bit integer.
In fact, we've been doing that for 64bits on 32bits hardwarde and OS for a
long long time, so it wouldn't be anything new.



>
>
>> The overflow detection is just an extra step, and it's only required
>> because (or rather IFF) the result is needed to be converted into the same
>> type as the operands.
>>
>
> The result is calculated to whatever precision is required to avoid
> overflow. When the result is assigned somewhere - then the overflow is
> caught.  So
>
> safe<int16> a, b;
> safe<int16> x = a + b; // could trap on overflow - but
> safe<int32> x = a + b; // would never trap
>
> An interesting side issue of this is that there is no run time overhead on
> the second
> statement because template meta programming is used to determine that
> there can never, ever be an overflow. Finally
>
> auto x = a + b; will result in x being of type safe<int32> and will never,
> ever trap( actually I have to double check this).
>
>
So what's the signature of operator+ ( safe<int64>, safe<int64> ) ?


> So to my mind this is exactly what is desired.
>

So we are mostly agreeing on what is useful, only not on the interface.

I still prefer something more general that would allow me to do:

int16 a,b ;
int32 x = safe_add(a,b);

and entirely bypass the wrapper though, specially as a std utility (which
is what we are discussing here)


>
> That means that both libraries under consideration are really the
>> composition of two layers: the bottom layer that performs the operation in
>> a way that it's result is known to be correct, and the layer that performs
>> the conversion to a given receiving type but doing a proper range check
>> first.
>>
>
> In my implementation, the two layers are there - but can't be separated.
> The "lower" layer happens on the + operator while the "upper" layer happens
> on the = operator.  There is only one library though.
>
>
Notice that this is not the case of the SafeInt (and SafeInt does not allow
me to just get the correct, non-overflowed result as we did above)


> Then I'm saying that, since the bottom layer is a requirement for these
> libraries, and it's also useful--and used--in several other numerical
> techniques, it should be standardized as such (and not hidden as an
> implementation detail as it proposed)
>
> I'm guessing that anyone wanting to do this could just overload the =
> operator. or use safe<?> as a constructor argument to his own special type.
>
>
> But that's not all.
>
> I'm also saying that the bigger picture could critically affect design
> decision even within the scope proposed. I gave the example of certified
> arithmetic because that would suggest that a given safe_int should not
> necessarily just throw right up front, but it could instead flag the
> overflow and throw only when necessary, such as when casting to int. This
> is important because if you are going to compare the overflowed result, you
> can just return "maybe" from the comparison without throwing an exception.
> This not only allows the client code to be *elegantly* explicit about the
> way overflowed results affect the computation results, but it also allows
> the library to be used in contexts where exceptions are to be avoided when
> possible.
>
> as a practical matter, I don't see how you can "throw upfront" until you
> actually do an assignment or explicit cast.  Take the following assignment.
>
> Indeed my point was that you shouldn't, but you certainly could (and
naturally would) in a design that does not separate the two layers.

The SafeInt code, for example, (and AFAICT), does just that, since it
doesn't produce a 2N bits integer for an operation between two N bits
integers. So it checks and throws right in the operators (actually the
functions that produce the results, to be precise)




> safe<int16> a;
> safe<int32> b;
>
> auto x = a + b;  // what is the type of x?
>

should be safe<int64>


> auto x = b + a;  // is the type of y the same as the type of x?
>
> yes


> Questions like these made me decide to divide the task as you suggested
> a) do the calculation resulting in a type which can hold the true result
> b) on assignment or cast (safe_cast ...) trap the attempt to save a value
> which loses information.
>
>
So we are almost on the same page.

We differ in how to propose two two layers to the std


Best


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b3436a2f517a604cf1d51f5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Thu, Nov 22, 2=
012 at 7:25 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:robertmacleranrame=
y@gmail.com" target=3D"_blank">robertmacleranramey@gmail.com</a>&gt;</span>=
 wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>On Thursday, November 22, 2012 1:33:=
38 PM UTC-8, Fernando Cacciola wrote:<div class=3D"im"><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

<div><div class=3D"gmail_quote">On Thu, Nov 22, 2012 at 5:57 PM,  <span dir=
=3D"ltr">&lt;<a>robertmac...@gmail.com</a><u></u>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><br>On Thursday,=
 November 22, 2012 9:02:42 AM UTC-8, Fernando Cacciola wrote:</div>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div>OK, I agree with you=
r observations about silently overloading operators.<br><br></div>

OTOH, ....</blockquote><div><br>Well one can make this very elaborate.=A0 W=
hen I was doing this I experimented with keep track of number of bits a com=
pile time so that operations which could never overthrow would generate no =
runtime overhead.=A0 There are lots of things one could do along this line =
- especially now that we have something like auto.<br>



<br>But in the end, I decided to keep it as simple as I could. The whole li=
brary can be summarized in one sentence.<br><br>&quot;any operation involvi=
ng a safe numeric type will produce the expected mathematical result or thr=
ow an exception&quot;<br>



<br>Making it do more or less than this would severely hamper it&#39;s util=
ity.<br><br></div></blockquote><div>=A0</div><div><span><font color=3D"#888=
888">=A0<br>
</font></span></div></div>I didn&#39;t intend to suggest that a library sho=
uld do less or more than proposed here. I suggested that in order to prepar=
e and evaluate such a proposal, the bigger picture should be taken into acc=
ount.<br>



<br>For instance, both SafeInt&#39;s and your code *requires* a primitive o=
peration that returns the result in a larger type such that it is known not=
 to overflow. </div></blockquote></div><div><br>I don&#39;t think that&#39;=
s true.=A0 That&#39;s not part of the interface or type requirements. It&#3=
9;s merely an implementation feature of the library because it&#39;s the fa=
stest way to do this.=A0 It still checks for overflows on int64 operations =
even though there is not int 128 type - it has to use a much slower method.=
<br>

<br></div></blockquote><div>I haven&#39;t checked your code in this corner =
case, but SafeInt uses a form of 128 bits type (when configured as such)<br=
><br>Since it is always true that the result of an integer operation betwee=
n two N bits integer fits perfectly in a 2*N bits integer, it is entirely p=
ossible to generalize the pattern even for 64bits by providing a library-ba=
sed 128bit integer.<br>

In fact, we&#39;ve been doing that for 64bits on 32bits hardwarde and OS fo=
r a long long time, so it wouldn&#39;t be anything new.<br><br>=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">

<div>=A0</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v>The overflow detection is just an extra step, and it&#39;s only required =
because (or rather IFF) the result is needed to be converted into the same =
type as the operands. </div>

</blockquote></div><div><br>The result is calculated to whatever precision =
is required to avoid overflow. When the result is assigned somewhere - then=
 the overflow is caught.=A0 So <br><br>safe&lt;int16&gt; a, b;<br>safe&lt;i=
nt16&gt; x =3D a + b; // could trap on overflow - but<br>

safe&lt;int32&gt; x =3D a + b; // would never trap<br><br>An interesting si=
de issue of this is that there is no run time overhead on the second<br>sta=
tement because template meta programming is used to determine that<br>there=
 can never, ever be an overflow. Finally<br>

<br>auto x =3D a + b; will result in x being of type safe&lt;int32&gt; and =
will never, ever trap( actually I have to double check this).<br><br></div>=
</blockquote><div><br>So what&#39;s the signature of operator+ ( safe&lt;in=
t64&gt;, safe&lt;int64&gt; ) ?<br>

=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div>So to my mind this is exactly =
what is desired.<br></div></blockquote><div><br>So we are mostly agreeing o=
n what is useful, only not on the interface.<br>

<br>I still prefer something more general that would allow me to do:<br><br=
>int16 a,b ;<br>int32 x =3D safe_add(a,b);<br><br>and entirely bypass the w=
rapper though, specially as a std utility (which is what we are discussing =
here)<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div></div><div class=3D"im"><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>That means that both libraries under consideration are really the comp=
osition of two layers: the bottom layer that performs the operation in a wa=
y that it&#39;s result is known to be correct, and the layer that performs =
the conversion to a given receiving type but doing a proper range check fir=
st.<br>

</div></blockquote></div><div><br>In my implementation, the two layers are =
there - but can&#39;t be separated.=A0 The &quot;lower&quot; layer happens =
on the + operator while the &quot;upper&quot; layer happens on the =3D oper=
ator.=A0 There is only one library though.<div class=3D"im">

<br></div></div></blockquote><div><br>Notice that this is not the case of t=
he SafeInt (and SafeInt does not allow me to just get the correct, non-over=
flowed result as we did above)<br><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div class=3D"im">=A0<br>Then I&#39;m saying that, since the bottom la=
yer is a requirement for these libraries, and it&#39;s also useful--and use=
d--in several other numerical techniques, it should be standardized as such=
 (and not hidden as an implementation detail as it proposed)<br>

<br></div>I&#39;m guessing that anyone wanting to do this could just overlo=
ad the =3D operator. or use safe&lt;?&gt; as a constructor argument to his =
own special type.<div class=3D"im"><br>

<br>But that&#39;s not all.<br><br>I&#39;m also saying that the bigger pict=
ure could critically affect design decision even within the scope proposed.=
 I gave the example of certified arithmetic because that would suggest that=
 a given safe_int should not necessarily just throw right up front, but it =
could instead flag the overflow and throw only when necessary, such as when=
 casting to int. This is important because if you are going to compare the =
overflowed result, you can just return &quot;maybe&quot; from the compariso=
n without throwing an exception. This not only allows the client code to be=
 *elegantly* explicit about the way overflowed results affect the computati=
on results, but it also allows the library to be used in contexts where exc=
eptions are to be avoided when possible.<br>

<br></div>as a practical matter, I don&#39;t see how you can &quot;throw up=
front&quot; until you actually do an assignment or explicit cast.=A0 Take t=
he following assignment.<br><br></div></blockquote><div>Indeed my point was=
 that you shouldn&#39;t, but you certainly could (and naturally would) in a=
 design that does not separate the two layers.<br>

<br>The SafeInt code, for example, (and AFAICT), does just that, since it d=
oesn&#39;t produce a 2N bits integer for an operation between two N bits in=
tegers. So it checks and throws right in the operators (actually the functi=
ons that produce the results, to be precise)<br>

<br><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div>safe&lt;int16&gt; a;<b=
r>safe&lt;int32&gt; b;<br><br>auto x =3D a + b;=A0 // what is the type of x=
?<br>
</div>
</blockquote><div><br>should be safe&lt;int64&gt;<br>=A0<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div>auto x =3D b + a;=A0 // is the type of y the sam=
e as the type of x?<br>

<br></div></blockquote><div>yes<br>=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div>Questions like these made me decide to divide the task as you sugg=
ested<br>

a) do the calculation resulting in a type which can hold the true result<br=
>b) on assignment or cast (safe_cast ...) trap the attempt to save a value =
which loses information.<br><br></div></blockquote><div><br>So we are almos=
t on the same page.<br>

<br>We differ in how to propose two two layers to the std<br><br></div></di=
v><br>Best<br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSoft Con=
sulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">http://ww=
w.scisoft-consulting.com</a><br>


</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3436a2f517a604cf1d51f5--

.

------=_Part_185_31242872.1353636624162
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, November 22, 2012 2:57:26 PM UTC-6, robertmac...@gmail.com
wrote:
>
> Well one can make this very elaborate.  When I was doing this I
> experimented with keep track of number of bits a compile time so that
> operations which could never overthrow would generate no runtime overhead.
> There are lots of things one could do along this line - especially now that
> we have something like auto.


That would likely turn into a fixed-point arithmetic<http://en.wikipedia.org/wiki/Fixed-point_arithmetic>library.

--




------=_Part_185_31242872.1353636624162
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, November 22, 2012 2:57:26 PM UTC-6, robertmac...@gmail=
..com wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px=
 solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">Well o=
ne can make this very elaborate.&nbsp; When I was doing this I experimented=
 with keep track of number of bits a compile time so that operations which =
could never overthrow would generate no runtime overhead.&nbsp; There are l=
ots of things one could do along this line - especially now that we have so=
mething like auto.</blockquote><div>&nbsp;<br>That would likely turn into a=
 <a href=3D"http://en.wikipedia.org/wiki/Fixed-point_arithmetic">fixed-poin=
t arithmetic</a> library.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_185_31242872.1353636624162--

.

------=_Part_84_8905187.1353653109551
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, November 22, 2012 6:10:24 PM UTC-8, Ben Craig wrote:
>
>
>
> That would likely turn into a fixed-point arithmetic<http://en.wikipedia.org/wiki/Fixed-point_arithmetic>library.
>

I believe that a multi-precision library has recently been submitted to
boost by john maddock.  It would be my hope that save<T> would work with
any type which has std::limits<T> implemented and the member limits has the
right definitions.  I haven't spent any time considering whether this is
possible though.  I did define and implement a "Numeric" concept which
includes all the intergers and the safe versions of the same in order to
support such an idea.  But I don't know whether this will really pan out or
not.  My main motivation was to make a "boostified" version of SafeInt.

Off topic - but related note.  In the course of doing this, I spent time
investigating Boost conversion which I believe you wrote.  I really
couldn't understand how to use it from the documentation  and filed a track
issue to that effect.  To my knowledge it's still a pending issue.  I think
some more effort in this area would be very helpful.

Robert Ramey


--




------=_Part_84_8905187.1353653109551
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, November 22, 2012 6:10:24 PM UTC-8, Ben Craig wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><br><div>&nbsp;<br>That would li=
kely turn into a <a href=3D"http://en.wikipedia.org/wiki/Fixed-point_arithm=
etic" target=3D"_blank">fixed-point arithmetic</a> library.<br></div></bloc=
kquote><div><br>I believe that a multi-precision library has recently been =
submitted to boost by john maddock.&nbsp; It would be my hope that save&lt;=
T&gt; would work with any type which has std::limits&lt;T&gt; implemented a=
nd the member limits has the right definitions.&nbsp; I haven't spent any t=
ime considering whether this is possible though.&nbsp; I did define and imp=
lement a "Numeric" concept which includes all the intergers and the safe ve=
rsions of the same in order to support such an idea.&nbsp; But I don't know=
 whether this will really pan out or not.&nbsp; My main motivation was to m=
ake a "boostified" version of SafeInt.<br><br>Off topic - but related note.=
&nbsp; In the course of doing this, I spent time investigating Boost conver=
sion which I believe you wrote.&nbsp; I really couldn't understand how to u=
se it from the documentation&nbsp; and filed a track issue to that effect.&=
nbsp; To my knowledge it's still a pending issue.&nbsp; I think some more e=
ffort in this area would be very helpful.<br><br>Robert Ramey<br>&nbsp;<br>=
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_84_8905187.1353653109551--

.

--047d7b34392e23421304cf28b0ce
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 23, 2012 at 3:45 AM, <robertmacleranramey@gmail.com> wrote:

>
>
> On Thursday, November 22, 2012 6:10:24 PM UTC-8, Ben Craig wrote:
>>
>>
>>
>> That would likely turn into a fixed-point arithmetic<http://en.wikipedia.org/wiki/Fixed-point_arithmetic>library.
>>
>
>
I would rather say that a fixed-point library, as well as a rationals
library, would be alongside (or maybe one level above) safe-int, as opposed
to a generalization of it.


> I believe that a multi-precision library has recently been submitted to
> boost by john maddock.  It would be my hope that save<T> would work with
> any type which has std::limits<T> implemented and the member limits has the
> right definitions.  I haven't spent any time considering whether this is
> possible though.  I did define and implement a "Numeric" concept which
> includes all the intergers and the safe versions of the same in order to
> support such an idea.  But I don't know whether this will really pan out or
> not.  My main motivation was to make a "boostified" version of SafeInt.
>
> I still prefer a traits and functions only lower layer because it would be
naturally used in the implementation of a fixed_point<T> and rational<T>,
but I admit that they could just as well use safe_int<T>, as has been
presented.

Here's one example off the top of my head about why I would prefer a lower
layer independent of safe_int<>

Both fixed_point<T> and rational<T> are useful as long as the values do not
overflow. However, and this is particularly true in the case of rationals,
there are several application domains where computations can easily, and
often, overflow. In these cases, one must use a big_int (unlimited
precision integer) as T (whether for a fixed_point or rational)
But that is pessimistically inefficient, so one would consider a
non-template "exact" numeric type which would have a dynamic internal
representation of rational<T> but which would automatically switch from T
to 2T (meaning a two times bigger integer), until it reaches big_int.

Now, if rational<T> uses internally safe<T>, how would we determine the
next representation to use when overflow is detected? would it do something
like

rational< typename decltype( safe<T> + safe<T> )::internal_type > ?

that'd work but it starts getting cumbersome.

If, OTOH, safe<T>, rational<T>, fixed_point<T> and exact, they all use the
same general lower layer with elements such as :

exact_integer_result_type<T,T>::type  // given int32,int32 yields int64

safe_add(T,T) -> exact_integer_result_type<T,T>::type

etc...

then the promoted rational to use within exact would be

rational< typename exact_integer_result_type<T,T>::type >

which looks a lot clean to me.

That's all off the top of my head, but I hope it illustrates my point.




> Off topic - but related note.  In the course of doing this, I spent time
> investigating Boost conversion which I believe you wrote.  I really
> couldn't understand how to use it from the documentation  and filed a track
> issue to that effect.  To my knowledge it's still a pending issue.  I think
> some more effort in this area would be very helpful.
>
>
Absolutely. Fixing that documentation is in my close-term TODO list

Best


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b34392e23421304cf28b0ce
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Nov 23, 2=
012 at 3:45 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:robertmacleranrame=
y@gmail.com" target=3D"_blank">robertmacleranramey@gmail.com</a>&gt;</span>=
 wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im"><br><br=
>On Thursday, November 22, 2012 6:10:24 PM UTC-8, Ben Craig wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">

<br><div>=A0<br>That would likely turn into a <a href=3D"http://en.wikipedi=
a.org/wiki/Fixed-point_arithmetic" target=3D"_blank">fixed-point arithmetic=
</a> library.<br></div></blockquote></div><div><br></div></blockquote><div>=
<br>

I would rather say that a fixed-point library, as well as a rationals libra=
ry, would be alongside (or maybe one level above) safe-int, as opposed to a=
 generalization of it.<br>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">

<div>I believe that a multi-precision library has recently been submitted t=
o boost by john maddock.=A0 It would be my hope that save&lt;T&gt; would wo=
rk with any type which has std::limits&lt;T&gt; implemented and the member =
limits has the right definitions.=A0 I haven&#39;t spent any time consideri=
ng whether this is possible though.=A0 I did define and implement a &quot;N=
umeric&quot; concept which includes all the intergers and the safe versions=
 of the same in order to support such an idea.=A0 But I don&#39;t know whet=
her this will really pan out or not.=A0 My main motivation was to make a &q=
uot;boostified&quot; version of SafeInt.<br>

<br></div></blockquote><div>I still prefer a traits and functions only lowe=
r layer because it would be naturally used in the implementation of a fixed=
_point&lt;T&gt; and rational&lt;T&gt;, but I admit that they could just as =
well use safe_int&lt;T&gt;, as has been presented.<br>

<br>Here&#39;s one example off the top of my head about why I would prefer =
a lower layer independent of safe_int&lt;&gt;<br><br>Both fixed_point&lt;T&=
gt; and rational&lt;T&gt; are useful as long as the values do not overflow.=
 However, and this is particularly true in the case of rationals, there are=
 several application domains where computations can easily, and often, over=
flow. In these cases, one must use a big_int (unlimited precision integer) =
as T (whether for a fixed_point or rational)<br>

But that is pessimistically inefficient, so one would consider a non-templa=
te &quot;exact&quot; numeric type which would have a dynamic internal repre=
sentation of rational&lt;T&gt; but which would automatically switch from T =
to 2T (meaning a two times bigger integer), until it reaches big_int.<br>

<br>Now, if rational&lt;T&gt; uses internally safe&lt;T&gt;, how would we d=
etermine the next representation to use when overflow is detected? would it=
 do something like<br><br>rational&lt; typename decltype( safe&lt;T&gt; + s=
afe&lt;T&gt; )::internal_type &gt; ?<br>

<br>that&#39;d work but it starts getting cumbersome.<br><br>If, OTOH, safe=
&lt;T&gt;, rational&lt;T&gt;, fixed_point&lt;T&gt; and exact, they all use =
the same general lower layer with elements such as :<br><br>exact_integer_r=
esult_type&lt;T,T&gt;::type=A0 // given int32,int32 yields int64<br>

<br>safe_add(T,T) -&gt; exact_integer_result_type&lt;T,T&gt;::type<br><br>e=
tc...<br><br>then the promoted rational to use within exact would be<br><br=
>rational&lt; typename exact_integer_result_type&lt;T,T&gt;::type &gt;<br>

<br>which looks a lot clean to me.<br><br>That&#39;s all off the top of my =
head, but I hope it illustrates my point.<br><br><br>=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">

<div>Off topic - but related note.=A0 In the course of doing this, I spent =
time investigating Boost conversion which I believe you wrote.=A0 I really =
couldn&#39;t understand how to use it from the documentation=A0 and filed a=
 track issue to that effect.=A0 To my knowledge it&#39;s still a pending is=
sue.=A0 I think some more effort in this area would be very helpful.<br>

<br></div></blockquote><div><br>Absolutely. Fixing that documentation is in=
 my close-term TODO list<br><br>Best<br>=A0<br></div></div><br>-- <br>Ferna=
ndo Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisof=
t-consulting.com">http://www.scisoft-consulting.com</a><br>


</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b34392e23421304cf28b0ce--

.

------=_Part_197_11725922.1353690631293
Content-Type: text/plain; charset=ISO-8859-1



On Friday, November 23, 2012 4:26:08 AM UTC-8, Fernando Cacciola wrote:
>
>
> On Fri, Nov 23, 2012 at 3:45 AM, <robertmac...@gmail.com <javascript:>>wrote:
>
>>
>>
>> On Thursday, November 22, 2012 6:10:24 PM UTC-8, Ben Craig wrote:
>>>
>>>
>>>
>>> That would likely turn into a fixed-point arithmetic<http://en.wikipedia.org/wiki/Fixed-point_arithmetic>library.
>>>
>>
>>
> I would rather say that a fixed-point library, as well as a rationals
> library, would be alongside (or maybe one level above) safe-int, as opposed
> to a generalization of it.
>


I'm not sure I followed your suggestion, but somehow I'm thinking I might
be in agreement. My view would be the "safe" idea would be orthogonal to
the "numeric" idea.  So

int, rational<T>, multiprecision<N>, .... would have std limits<T> defined.
std::limits includes members to define min/max values and a lot of other
features of numeric types.

This would make them fullfill the "Numeric" concept (type requirements).

safe<T> would be defined for any type T fullfilling the "Numeric" concept.

and safe<T> would also have std::limits implemented so it would fullfill
the "Numeric" concept as well.

This would separate the "safe" idea from the "numeric" idea and permit
users to use the "safe" version if and only if actually desired.  It would
also clarify what "safe" does as opposed to what "numeric" does.  My
proposal implements this idea for current integer types.  It hasn't really
been investigated whether this extends well to all integer types for which
std::limits is implemented.  Anyway, this is far into the future.

Robert Ramey

--




------=_Part_197_11725922.1353690631293
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, November 23, 2012 4:26:08 AM UTC-8, Fernando Cacciola wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br><div class=3D"gma=
il_quote">On Fri, Nov 23, 2012 at 3:45 AM,  <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"0-HkoyxGrxwJ">r=
obertmac...@gmail.com</a><wbr>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><br>On Thursday,=
 November 22, 2012 6:10:24 PM UTC-8, Ben Craig wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">

<br><div>&nbsp;<br>That would likely turn into a <a href=3D"http://en.wikip=
edia.org/wiki/Fixed-point_arithmetic" target=3D"_blank">fixed-point arithme=
tic</a> library.<br></div></blockquote></div><div><br></div></blockquote><d=
iv><br>

I would rather say that a fixed-point library, as well as a rationals libra=
ry, would be alongside (or maybe one level above) safe-int, as opposed to a=
 generalization of it.<br></div></div></div></blockquote><div><br><br>I'm n=
ot sure I followed your suggestion, but somehow I'm thinking I might be in =
agreement. My view would be the "safe" idea would be orthogonal to the "num=
eric" idea.&nbsp; So<br><br>int, rational&lt;T&gt;, multiprecision&lt;N&gt;=
, .... would have std limits&lt;T&gt; defined. std::limits includes members=
 to define min/max values and a lot of other features of numeric types.<br>=
<br>This would make them fullfill the "Numeric" concept (type requirements)=
..<br><br>safe&lt;T&gt; would be defined for any type T fullfilling the "Num=
eric" concept.<br><br>and safe&lt;T&gt; would also have std::limits impleme=
nted so it would fullfill the "Numeric" concept as well.<br><br>This would =
separate the "safe" idea from the "numeric" idea and permit users to use th=
e "safe" version if and only if actually desired.&nbsp; It would also clari=
fy what "safe" does as opposed to what "numeric" does.&nbsp; My proposal im=
plements this idea for current integer types.&nbsp; It hasn't really been i=
nvestigated whether this extends well to all integer types for which std::l=
imits is implemented.&nbsp; Anyway, this is far into the future.<br><br>Rob=
ert Ramey<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_197_11725922.1353690631293--

.

------=_Part_50_4562325.1353862767029
Content-Type: text/plain; charset=ISO-8859-1

A few facts I wanted to share:

uint32 a= random<uint32>();
uint32 b= random<uint32>();
bool carry= random<bool>();
uint33 c= a + b + carry; //this cannot overflow

In this example, the integer type that stores automatic results must know
the exact maximum, not the number of bits of the sub result. Also, a
multiplication of two Nbits number cannot give the maximum of a 2*Nbits
number.

It might be possible to define a 128bits integer as a pair of low bits and
high bits. And then generalize for N*64bits number. All of those numbers
could know their exact minimum and maximum at compile time. Multiplication
algorithm of large numbers often add several results of the multiplication
of 2 machine words. Many overflow check could be removed if the integer
type knows its exact minimum and maximum.

--




------=_Part_50_4562325.1353862767029
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

A few facts I wanted to share:<br><br>uint32 a=3D random&lt;uint32&gt;();<b=
r>uint32 b=3D random&lt;uint32&gt;();<br>bool carry=3D random&lt;bool&gt;()=
;<br>uint33 c=3D a + b + carry; //this cannot overflow<br><br>In this examp=
le, the integer type that stores automatic results must know the exact maxi=
mum, not the number of bits of the sub result. Also, a multiplication of tw=
o Nbits number cannot give the maximum of a 2*Nbits number.<br><br>It might=
 be possible to define a 128bits integer as a pair of low bits and high bit=
s. And then generalize for N*64bits number. All of those numbers could know=
 their exact minimum and maximum at compile time. Multiplication algorithm =
of large numbers often add several results of the multiplication of 2 machi=
ne words. Many overflow check could be removed if the integer type knows it=
s exact minimum and maximum.<br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_50_4562325.1353862767029--

.

------=_Part_61_27471248.1353864691909
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, November 25, 2012 8:59:27 AM UTC-8, Marc Thibault wrote:
>
> A few facts I wanted to share:...
>
> Many overflow check could be removed if the integer type knows its exact
> minimum and maximum.
>

The library I cited -
http://rrsd.com/blincubator.com/bi_library/safe-numerics/ does exactly
that.  That is using TMP techniques - it elides the overflow check if it
can be determined that the result can never overflow.

Robert Ramey

--




------=_Part_61_27471248.1353864691909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, November 25, 2012 8:59:27 AM UTC-8, Marc Thibault wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">A few facts I wanted to share:=
....<br><br>Many overflow check could be removed if the integer type knows i=
ts exact minimum and maximum.<br></blockquote><div><br>The library I cited =
- http://rrsd.com/blincubator.com/bi_library/safe-numerics/ does exactly th=
at.&nbsp; That is using TMP techniques - it elides the overflow check if it=
 can be determined that the result can never overflow.<br><br>Robert Ramey<=
br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_61_27471248.1353864691909--

.

------=_Part_266_1191357.1353868278271
Content-Type: text/plain; charset=ISO-8859-1

I also believe that safe-numerics is very good. I think the problem of
integers that grows at runtime has to be done in a different library. Also,
there is the independent problem of creating efficient accumulators.

safe_int<int64_t> i;
i.accumulate(uint32_t* first, uint32_t* last);

The number of overflow check could be greatly reduced in the above equation.



On Sunday, November 25, 2012 12:31:32 PM UTC-5, robertmac...@gmail.com
wrote:
>
>
>
> On Sunday, November 25, 2012 8:59:27 AM UTC-8, Marc Thibault wrote:
>>
>> A few facts I wanted to share:...
>>
>> Many overflow check could be removed if the integer type knows its exact
>> minimum and maximum.
>>
>
> The library I cited -
> http://rrsd.com/blincubator.com/bi_library/safe-numerics/ does exactly
> that.  That is using TMP techniques - it elides the overflow check if it
> can be determined that the result can never overflow.
>
> Robert Ramey
>

--




------=_Part_266_1191357.1353868278271
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I also believe that safe-numerics is very good. I think the problem of inte=
gers that grows at runtime has to be done in a different library. Also, the=
re is the independent problem of creating efficient accumulators.<br><br>sa=
fe_int&lt;int64_t&gt; i;<br>i.accumulate(uint32_t* first, uint32_t* last);<=
br><br>The number of overflow check could be greatly reduced in the above e=
quation.<br><br><br><br>On Sunday, November 25, 2012 12:31:32 PM UTC-5, rob=
ertmac...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>=
<br>On Sunday, November 25, 2012 8:59:27 AM UTC-8, Marc Thibault wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">A few facts I wanted to share:...<br><b=
r>Many overflow check could be removed if the integer type knows its exact =
minimum and maximum.<br></blockquote><div><br>The library I cited - <a href=
=3D"http://rrsd.com/blincubator.com/bi_library/safe-numerics/" target=3D"_b=
lank">http://rrsd.com/blincubator.<wbr>com/bi_library/safe-numerics/</a> do=
es exactly that.&nbsp; That is using TMP techniques - it elides the overflo=
w check if it can be determined that the result can never overflow.<br><br>=
Robert Ramey<br></div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_266_1191357.1353868278271--

.

------=_Part_25_9392381.1353874166176
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, November 25, 2012 10:31:18 AM UTC-8, Marc Thibault wrote:
>
> I also believe that safe-numerics is very good. I think the problem of
> integers that grows at runtime has to be done in a different library. Also,
> there is the independent problem of creating efficient accumulators.
>
> safe_int<int64_t> i;
> i.accumulate(uint32_t* first, uint32_t* last);
>
> The number of overflow check could be greatly reduced in the above
> equation.
>

The SafeInt as well as safe<int64> don't have an accumulate function.  They
are meant to be drop-in replacements for the base type int64.  Adding a new
interface would be a whole new kettle of fish.

Besides,  dont' think anything more is needed though.

safe<int64> total;

for(..
    int32 x.
   ....
    total += x;
}
would work just fine and throws if the total were to overflow.

Robert Ramey

--




------=_Part_25_9392381.1353874166176
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, November 25, 2012 10:31:18 AM UTC-8, Marc Thibault wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">I also believe that safe-nume=
rics is very good. I think the problem of integers that grows at runtime ha=
s to be done in a different library. Also, there is the independent problem=
 of creating efficient accumulators.<br><br>safe_int&lt;int64_t&gt; i;<br>i=
..accumulate(uint32_t* first, uint32_t* last);<br><br>The number of overflow=
 check could be greatly reduced in the above equation.<br></blockquote><div=
><br>The SafeInt as well as safe&lt;int64&gt; don't have an accumulate func=
tion.&nbsp; They are meant to be drop-in replacements for the base type int=
64.&nbsp; Adding a new interface would be a whole new kettle of fish.<br><b=
r>Besides,&nbsp; dont' think anything more is needed though.<br><br>safe&lt=
;int64&gt; total;<br><br>for(..<br>&nbsp;&nbsp;&nbsp; int32 x.<br>&nbsp;&nb=
sp; ....<br>&nbsp;&nbsp;&nbsp; total +=3D x;<br>}<br>would work just fine a=
nd throws if the total were to overflow.<br><br>Robert Ramey<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_25_9392381.1353874166176--

.

Le 25/11/12 19:31, Marc Thibault a =E9crit :
> I also believe that safe-numerics is very good. I think the problem of=20
> integers that grows at runtime has to be done in a different library.=20
> Also, there is the independent problem of creating efficient accumulators=
..
>
> safe_int<int64_t> i;
> i.accumulate(uint32_t* first, uint32_t* last);
>
> The number of overflow check could be greatly reduced in the above=20
> equation.

Well all this depends of the initial value of i. If it is 0, I agree=20
that a accumulate member  function could avoid lost of the overloads checks=
..
I will suggest then that the accumulate function be a free function and=20
return just a int64_t, so the result initialization is mastered by the=20
algorithm.

-- Vicente

--=20




.

This is a multi-part message in MIME format.
--------------030608080201030508070407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 08/11/12 03:59, Ben Craig a =E9crit :
> SafeInt information can be found here <http://safeint.codeplex.com/>.=20
> Basically, it is an open source library authored by security expert=20
> David LeBlanc of Microsoft.  It is basically a "drop-in" replacement=20
> for integer types, and will throw an exception whenever integer=20
> overflows occur.  I believe that getting this added to the standard=20
> would be a boon to C++ and secure code.  It should be a relatively low=20
> effort addition considering the "proof-of-concept" is already widely=20
> used within Microsoft.
> --=20
>
>
>
Hi,

have you take a look at "C++ Binary Fixed-Point Arithmetic"=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html?

It seems to respond to most of the problems (if not all) you try to solve.

Could you comment features you want  that this proposal doesn't covers?

-- Vicente

--=20




--------------030608080201030508070407
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 08/11/12 03:59, Ben Craig a &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite="mid:604806bd-962c-4a49-a974-ddf34722867d@isocpp.org"
      type="cite">SafeInt information can be found <a
        moz-do-not-send="true" href="http://safeint.codeplex.com/">here</a>.&nbsp;
      Basically, it is an open source library authored by security
      expert David LeBlanc of Microsoft.&nbsp; It is basically a "drop-in"
      replacement for integer types, and will throw an exception
      whenever integer overflows occur.&nbsp; I believe that getting this
      added to the standard would be a boon to C++ and secure code.&nbsp; It
      should be a relatively low effort addition considering the
      "proof-of-concept" is already widely used within Microsoft.<br>
      -- <br>
      &nbsp;<br>
      &nbsp;<br>
      &nbsp;<br>
    </blockquote>
    Hi,<br>
    <br>
    have you take a look at "C++ Binary Fixed-Point Arithmetic"
    <a class="moz-txt-link-freetext" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html</a>?<br>
    <br>
    It seems to respond to most of the problems (if not all) you try to
    solve.<br>
    <br>
    Could you comment features you want&nbsp; that this proposal doesn't
    covers?<br>
    <br>
    -- Vicente<br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--------------030608080201030508070407--

.

------=_Part_186_3925609.1353881237955
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Sunday, November 25, 2012 1:39:58 PM UTC-8, viboes wrote:
>
>  Le 08/11/12 03:59, Ben Craig a =E9crit :
> =20
> Hi,
>
> have you take a look at "C++ Binary Fixed-Point Arithmetic"=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html?
>
> It seems to respond to most of the problems (if not all) you try to solve=
..
>
> Could you comment features you want  that this proposal doesn't covers?
>

Very interesting.  i don't know whether or not I saw this when I made my=20
version of safe<T>.

In general, I see it as very similar.  But there are some notable=20
differences.

"The fixed-point library contains four class templates. They are cardinalan=
d=20
integral for integer arithmetic, and nonnegative and negatable for=20
fractional arithmetic."

a) I use the integer traits defined by std::limits<T> to determined whether=
=20
the type is signed/unsigned, the max/min, etc. So instead of having a=20
variety of templates, there is only one using TMP to determine the traits.

b) I don't address fractions or rounding at all. =20

c) I considered a policy parameter of some sort to indicate how to handle=
=20
overflows - they use an enum to select.  But I rejected the idea for two=20
reasons

i) more complexity with very little value.
ii)  I couldn't see how to do it with something like

safe<int32> x;
safe<int16> y;
safe<int32> z;
z =3D x + y;  // where would the policy parameter go?

In the end, I re-focused on a drop-in replacement for all integer types. =
=20
"all integer types" means all types - instrinsic and user defined types for=
=20
which std::limit<T>::is_integer() return true.

To summarize,  SafeInt and safe<T> are different than the proposal in the=
=20
paper above.  But I believe they are better.

Robert Ramey


> -- Vicente
> =20

--=20




------=_Part_186_3925609.1353881237955
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, November 25, 2012 1:39:58 PM UTC-8, viboes wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 08/11/12 03:59, Ben Craig a =E9crit&nbsp;:<br>
    </div>
    <br>
    Hi,<br>
    <br>
    have you take a look at "C++ Binary Fixed-Point Arithmetic"
    <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n335=
2.html" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/=
papers/2012/<wbr>n3352.html</a>?<br>
    <br>
    It seems to respond to most of the problems (if not all) you try to
    solve.<br>
    <br>
    Could you comment features you want&nbsp; that this proposal doesn't
    covers?<br></div></blockquote><div><br>Very interesting.&nbsp; i don't =
know whether or not I saw this when I made my version of safe&lt;T&gt;.<br>=
<br>In general, I see it as very similar.&nbsp; But there are some notable =
differences.<br><br>"The fixed-point library contains four class templates.
They are <code>cardinal</code> and <code>integral</code>
for integer arithmetic,
and <code>nonnegative</code> and <code>negatable</code>
for fractional arithmetic."<br><br>a) I use the integer traits defined by s=
td::limits&lt;T&gt; to determined whether the type is signed/unsigned, the =
max/min, etc. So instead of having a variety of templates, there is only on=
e using TMP to determine the traits.<br><br>b) I don't address fractions or=
 rounding at all.&nbsp; <br><br>c) I considered a policy parameter of some =
sort to indicate how to handle overflows - they use an enum to select.&nbsp=
; But I rejected the idea for two reasons<br><br>i) more complexity with ve=
ry little value.<br>ii)&nbsp; I couldn't see how to do it with something li=
ke<br><br>safe&lt;int32&gt; x;<br>safe&lt;int16&gt; y;<br>safe&lt;int32&gt;=
 z;<br>z =3D x + y;&nbsp; // where would the policy parameter go?<br><br>In=
 the end, I re-focused on a drop-in replacement for all integer types.&nbsp=
; "all integer types" means all types - instrinsic and user defined types f=
or which std::limit&lt;T&gt;::is_integer() return true.<br><br>To summarize=
,&nbsp; SafeInt and safe&lt;T&gt; are different than the proposal in the pa=
per above.&nbsp; But I believe they are better.<br><br>Robert Ramey<br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF"=
 text=3D"#000000">
    <br>
    -- Vicente<br>
  </div>

</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_186_3925609.1353881237955--

.

This is a multi-part message in MIME format.
--------------060201040707050101040704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 25/11/12 23:07, robertmacleranramey@gmail.com a =E9crit :
>
>
> On Sunday, November 25, 2012 1:39:58 PM UTC-8, viboes wrote:
>
>     Le 08/11/12 03:59, Ben Craig a =E9crit :
>
>     Hi,
>
>     have you take a look at "C++ Binary Fixed-Point Arithmetic"
>     http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html
>     <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html>?
>
>     It seems to respond to most of the problems (if not all) you try
>     to solve.
>
>     Could you comment features you want  that this proposal doesn't
>     covers?
>
>
> Very interesting.  i don't know whether or not I saw this when I made=20
> my version of safe<T>.
My question was addressed to the PO. Anyway ...
>
> In general, I see it as very similar.  But there are some notable=20
> differences.
>
> "The fixed-point library contains four class templates. They are=20
> |cardinal| and |integral| for integer arithmetic, and |nonnegative|=20
> and |negatable| for fractional arithmetic."
>
> a) I use the integer traits defined by std::limits<T> to determined=20
> whether the type is signed/unsigned, the max/min, etc. So instead of=20
> having a variety of templates, there is only one using TMP to=20
> determine the traits.
I don't see an added value at the user level. I'm open to variations.
>
> b) I don't address fractions or rounding at all.
Well, this is out of the PO subject, so no matter. I could understand=20
that we could want safe integers independently.
>
> c) I considered a policy parameter of some sort to indicate how to=20
> handle overflows - they use an enum to select.  But I rejected the=20
> idea for two reasons
>
> i) more complexity with very little value.
> ii)  I couldn't see how to do it with something like
>
> safe<int32> x;
> safe<int16> y;
> safe<int32> z;
> z =3D x + y;  // where would the policy parameter go?
With the Lawrence proposal you don't have overflow as far as you don't=20
loss range. So the natural place is to use it only with assignment.

integral<31,OV1> x;
integral<15,OV2> y;
integral<31,OV3> z;
z =3D x + y;

Check for overflow only when doing the assignment using the overflow OV3=20
policy.

The fact to add the overflow policy on the type makes the code less weight.

We can have also a base class for integral that has no overflow policy=20
and forbids assignment that can loss information

basic_integral<31> x;
basic_integral<15> y;
basic_integral<31> z;
z =3D x + y; // compile file

The user will need to use a number_cast conversion like in

z =3D number_cast<OV3>(x + y);

>
> In the end, I re-focused on a drop-in replacement for all integer=20
> types.  "all integer types" means all types - instrinsic and user=20
> defined types for which std::limit<T>::is_integer() return true.
>
> To summarize,  SafeInt and safe<T> are different than the proposal in=20
> the paper above.  But I believe they are better.
Humm, I need then to read both ;-) But do the PO proposal or your Safe=20
library allow to saturate on overflow, assert, ignore, ...?

Best,
Vicente

--=20




--------------060201040707050101040704
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 25/11/12 23:07,
      <a class="moz-txt-link-abbreviated" href="mailto:robertmacleranramey@gmail.com">robertmacleranramey@gmail.com</a> a &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite="mid:878ba062-6f25-4390-8130-7017720ca097@isocpp.org"
      type="cite"><br>
      <br>
      On Sunday, November 25, 2012 1:39:58 PM UTC-8, viboes wrote:
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <div bgcolor="#FFFFFF" text="#000000">
          <div>Le 08/11/12 03:59, Ben Craig a &eacute;crit&nbsp;:<br>
          </div>
          <br>
          Hi,<br>
          <br>
          have you take a look at "C++ Binary Fixed-Point Arithmetic" <a
            moz-do-not-send="true"
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html"
            target="_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2012/<wbr>n3352.html</a>?<br>
          <br>
          It seems to respond to most of the problems (if not all) you
          try to solve.<br>
          <br>
          Could you comment features you want&nbsp; that this proposal
          doesn't covers?<br>
        </div>
      </blockquote>
      <div><br>
        Very interesting.&nbsp; i don't know whether or not I saw this when I
        made my version of safe&lt;T&gt;.<br>
      </div>
    </blockquote>
    My question was addressed to the PO. Anyway ...<br>
    <blockquote
      cite="mid:878ba062-6f25-4390-8130-7017720ca097@isocpp.org"
      type="cite">
      <div><br>
        In general, I see it as very similar.&nbsp; But there are some
        notable differences.<br>
        <br>
        "The fixed-point library contains four class templates.
        They are <code>cardinal</code> and <code>integral</code>
        for integer arithmetic,
        and <code>nonnegative</code> and <code>negatable</code>
        for fractional arithmetic."<br>
        <br>
        a) I use the integer traits defined by std::limits&lt;T&gt; to
        determined whether the type is signed/unsigned, the max/min,
        etc. So instead of having a variety of templates, there is only
        one using TMP to determine the traits.<br>
      </div>
    </blockquote>
    I don't see an added value at the user level. I'm open to
    variations.<br>
    <blockquote
      cite="mid:878ba062-6f25-4390-8130-7017720ca097@isocpp.org"
      type="cite">
      <div><br>
        b) I don't address fractions or rounding at all.&nbsp; <br>
      </div>
    </blockquote>
    Well, this is out of the PO subject, so no matter. I could
    understand that we could want safe integers independently.<br>
    <blockquote
      cite="mid:878ba062-6f25-4390-8130-7017720ca097@isocpp.org"
      type="cite">
      <div><br>
        c) I considered a policy parameter of some sort to indicate how
        to handle overflows - they use an enum to select.&nbsp; But I
        rejected the idea for two reasons<br>
        <br>
        i) more complexity with very little value.<br>
        ii)&nbsp; I couldn't see how to do it with something like<br>
        <br>
        safe&lt;int32&gt; x;<br>
        safe&lt;int16&gt; y;<br>
        safe&lt;int32&gt; z;<br>
        z = x + y;&nbsp; // where would the policy parameter go?<br>
      </div>
    </blockquote>
    With the
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    Lawrence proposal you don't have overflow as far as you don't loss
    range. So the natural place is to use it only with assignment.<br>
    <br>
    <div>integral&lt;31,OV1&gt; x;<br>
      integral&lt;15,OV2&gt; y;<br>
      integral&lt;31,OV3&gt; z;<br>
      z = x + y;<br>
      <br>
      Check for overflow only when doing the assignment using the
      overflow OV3 policy. <br>
      <br>
      The fact to add the overflow policy on the type makes the code
      less weight.<br>
      <br>
      We can have also a base class for integral that has no overflow
      policy and forbids assignment that can loss information<br>
      <br>
      basic_integral&lt;31&gt; x;<br>
      basic_integral&lt;15&gt; y;<br>
      basic_integral&lt;31&gt; z;<br>
      z = x + y; // compile file<br>
      <br>
    </div>
    The user will need to use a number_cast conversion like in<br>
    <br>
    z = number_cast&lt;OV3&gt;(x + y);<br>
    <br>
    <blockquote
      cite="mid:878ba062-6f25-4390-8130-7017720ca097@isocpp.org"
      type="cite">
      <div><br>
        In the end, I re-focused on a drop-in replacement for all
        integer types.&nbsp; "all integer types" means all types - instrinsic
        and user defined types for which
        std::limit&lt;T&gt;::is_integer() return true.<br>
        <br>
        To summarize,&nbsp; SafeInt and safe&lt;T&gt; are different than the
        proposal in the paper above.&nbsp; But I believe they are better.<br>
      </div>
    </blockquote>
    Humm, I need then to read both ;-) But do the PO proposal or your
    Safe library allow to saturate on overflow, assert, ignore, ...?<br>
    <br>
    Best,<br>
    Vicente <br>
    <br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--------------060201040707050101040704--

.

This is a multi-part message in MIME format.
--------------060803060802000302080705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 26/11/12 08:17, Vicente J. Botet Escriba a =E9crit :
> Le 25/11/12 23:07, robertmacleranramey@gmail.com a =E9crit :
>>
>>
>> On Sunday, November 25, 2012 1:39:58 PM UTC-8, viboes wrote:
>>
>>     Le 08/11/12 03:59, Ben Craig a =E9crit :
>>
>>     Hi,
>>
>>     have you take a look at "C++ Binary Fixed-Point Arithmetic"
>>     http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html <=
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html>?
>>
>>     It seems to respond to most of the problems (if not all) you try
>>     to solve.
>>
>>     Could you comment features you want  that this proposal doesn't
>>     covers?
>>
>>
>> Very interesting.  i don't know whether or not I saw this when I made=20
>> my version of safe<T>.
> My question was addressed to the PO. Anyway ...
>>
>> In general, I see it as very similar.  But there are some notable=20
>> differences.
>>
>> "The fixed-point library contains four class templates. They are=20
>> |cardinal| and |integral| for integer arithmetic, and |nonnegative|=20
>> and |negatable| for fractional arithmetic."
>>
>> a) I use the integer traits defined by std::limits<T> to determined=20
>> whether the type is signed/unsigned, the max/min, etc. So instead of=20
>> having a variety of templates, there is only one using TMP to=20
>> determine the traits.
> I don't see an added value at the user level. I'm open to variations.
>>
>> b) I don't address fractions or rounding at all.
> Well, this is out of the PO subject, so no matter. I could understand=20
> that we could want safe integers independently.
>>
>> c) I considered a policy parameter of some sort to indicate how to=20
>> handle overflows - they use an enum to select.  But I rejected the=20
>> idea for two reasons
>>
>> i) more complexity with very little value.
>> ii)  I couldn't see how to do it with something like
>>
>> safe<int32> x;
>> safe<int16> y;
>> safe<int32> z;
>> z =3D x + y;  // where would the policy parameter go?
> With the Lawrence proposal you don't have overflow as far as you don't=20
> loss range. So the natural place is to use it only with assignment.
>
> integral<31,OV1> x;
> integral<15,OV2> y;
> integral<31,OV3> z;
> z =3D x + y;
>
> Check for overflow only when doing the assignment using the overflow=20
> OV3 policy.
>
> The fact to add the overflow policy on the type makes the code less=20
> weight.
>
> We can have also a base class for integral that has no overflow policy=20
> and forbids assignment that can loss information
>
> basic_integral<31> x;
> basic_integral<15> y;
> basic_integral<31> z;
> z =3D x + y; // compile file
>
> The user will need to use a number_cast conversion like in
>
> z =3D number_cast<OV3>(x + y);
>
>>
>> In the end, I re-focused on a drop-in replacement for all integer=20
>> types.  "all integer types" means all types - instrinsic and user=20
>> defined types for which std::limit<T>::is_integer() return true.
>>
>> To summarize,  SafeInt and safe<T> are different than the proposal in=20
>> the paper above.  But I believe they are better.
> Humm, I need then to read both ;-) But do the PO proposal or your Safe=20
> library allow to saturate on overflow, assert, ignore, ...?
>
Where can I get the documentation of the PO proposal?

I wanted to add. safe<T> could be defined as a alias of the fixed point=20
class.

-- Vicente

--=20




--------------060803060802000302080705
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 26/11/12 08:17, Vicente J. Botet
      Escriba a &eacute;crit&nbsp;:<br>
    </div>
    <blockquote cite="mid:50B3176D.4050003@wanadoo.fr" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">Le 25/11/12 23:07, <a
          moz-do-not-send="true" class="moz-txt-link-abbreviated"
          href="mailto:robertmacleranramey@gmail.com">robertmacleranramey@gmail.com</a>
        a &eacute;crit&nbsp;:<br>
      </div>
      <blockquote
        cite="mid:878ba062-6f25-4390-8130-7017720ca097@isocpp.org"
        type="cite"><br>
        <br>
        On Sunday, November 25, 2012 1:39:58 PM UTC-8, viboes wrote:
        <blockquote class="gmail_quote" style="margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor="#FFFFFF" text="#000000">
            <div>Le 08/11/12 03:59, Ben Craig a &eacute;crit&nbsp;:<br>
            </div>
            <br>
            Hi,<br>
            <br>
            have you take a look at "C++ Binary Fixed-Point Arithmetic"
            <a moz-do-not-send="true"
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html"
              target="_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2012/<wbr>n3352.html</a>?<br>
            <br>
            It seems to respond to most of the problems (if not all) you
            try to solve.<br>
            <br>
            Could you comment features you want&nbsp; that this proposal
            doesn't covers?<br>
          </div>
        </blockquote>
        <div><br>
          Very interesting.&nbsp; i don't know whether or not I saw this when
          I made my version of safe&lt;T&gt;.<br>
        </div>
      </blockquote>
      My question was addressed to the PO. Anyway ...<br>
      <blockquote
        cite="mid:878ba062-6f25-4390-8130-7017720ca097@isocpp.org"
        type="cite">
        <div><br>
          In general, I see it as very similar.&nbsp; But there are some
          notable differences.<br>
          <br>
          "The fixed-point library contains four class templates. They
          are <code>cardinal</code> and <code>integral</code> for
          integer arithmetic, and <code>nonnegative</code> and <code>negatable</code>
          for fractional arithmetic."<br>
          <br>
          a) I use the integer traits defined by std::limits&lt;T&gt; to
          determined whether the type is signed/unsigned, the max/min,
          etc. So instead of having a variety of templates, there is
          only one using TMP to determine the traits.<br>
        </div>
      </blockquote>
      I don't see an added value at the user level. I'm open to
      variations.<br>
      <blockquote
        cite="mid:878ba062-6f25-4390-8130-7017720ca097@isocpp.org"
        type="cite">
        <div><br>
          b) I don't address fractions or rounding at all.&nbsp; <br>
        </div>
      </blockquote>
      Well, this is out of the PO subject, so no matter. I could
      understand that we could want safe integers independently.<br>
      <blockquote
        cite="mid:878ba062-6f25-4390-8130-7017720ca097@isocpp.org"
        type="cite">
        <div><br>
          c) I considered a policy parameter of some sort to indicate
          how to handle overflows - they use an enum to select.&nbsp; But I
          rejected the idea for two reasons<br>
          <br>
          i) more complexity with very little value.<br>
          ii)&nbsp; I couldn't see how to do it with something like<br>
          <br>
          safe&lt;int32&gt; x;<br>
          safe&lt;int16&gt; y;<br>
          safe&lt;int32&gt; z;<br>
          z = x + y;&nbsp; // where would the policy parameter go?<br>
        </div>
      </blockquote>
      With the
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      Lawrence proposal you don't have overflow as far as you don't loss
      range. So the natural place is to use it only with assignment.<br>
      <br>
      <div>integral&lt;31,OV1&gt; x;<br>
        integral&lt;15,OV2&gt; y;<br>
        integral&lt;31,OV3&gt; z;<br>
        z = x + y;<br>
        <br>
        Check for overflow only when doing the assignment using the
        overflow OV3 policy. <br>
        <br>
        The fact to add the overflow policy on the type makes the code
        less weight.<br>
        <br>
        We can have also a base class for integral that has no overflow
        policy and forbids assignment that can loss information<br>
        <br>
        basic_integral&lt;31&gt; x;<br>
        basic_integral&lt;15&gt; y;<br>
        basic_integral&lt;31&gt; z;<br>
        z = x + y; // compile file<br>
        <br>
      </div>
      The user will need to use a number_cast conversion like in<br>
      <br>
      z = number_cast&lt;OV3&gt;(x + y);<br>
      <br>
      <blockquote
        cite="mid:878ba062-6f25-4390-8130-7017720ca097@isocpp.org"
        type="cite">
        <div><br>
          In the end, I re-focused on a drop-in replacement for all
          integer types.&nbsp; "all integer types" means all types -
          instrinsic and user defined types for which
          std::limit&lt;T&gt;::is_integer() return true.<br>
          <br>
          To summarize,&nbsp; SafeInt and safe&lt;T&gt; are different than
          the proposal in the paper above.&nbsp; But I believe they are
          better.<br>
        </div>
      </blockquote>
      Humm, I need then to read both ;-) But do the PO proposal or your
      Safe library allow to saturate on overflow, assert, ignore, ...?<br>
      <br>
    </blockquote>
    Where can I get the documentation of the PO proposal?<br>
    <br>
    I wanted to add. safe&lt;T&gt; could be defined as a alias of the
    fixed point class.<br>
    <br>
    -- Vicente<br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--------------060803060802000302080705--

.

--20cf303b433b02985804cf68dd8e
Content-Type: text/plain; charset=ISO-8859-1

Some large use cases for SafeInt are computing sizes for buffers and array
indices.  In these situations, you probably want to throw an exception, or
terminate the program.  Saturation, assertions in debug mode, and ignoring
aren't very good options from a security standpoint.

Are the saturate, debug assert, and ignore cases useful in some other
domain?  I can see some use for saturation in some cases where a (possibly
implicit) range check was already present.  For instance, if I'm doing some
calculations with the volume on my speakers, I may have an acceptable range
of 0 - 65,535.  If my math comes up with a volume of 100,000, then setting
the volume to 65,535 may be reasonable.  I don't know how often this kind
of thing comes up though.

If you stick to "drop-in" replacements, then I'm not sure if there's any
benefit to an "ignore" policy.  Ignore is equivalent to the raw type.
Fixed-point libraries could make use of it though.  Debug assertions aren't
any better from a security standpoint, but they could help discover bugs in
non-security critical code.

--




--20cf303b433b02985804cf68dd8e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Some large use cases for SafeInt are computing sizes for buffers and array =
indices.=A0 In these situations, you probably want to throw an exception, o=
r terminate the program.=A0 Saturation, assertions in debug mode, and ignor=
ing aren&#39;t very good options from a security standpoint.<br>
<br>Are the saturate, debug assert, and ignore cases useful in some other d=
omain?=A0 I can see some use for saturation in some cases where a (possibly=
 implicit) range check was already present.=A0 For instance, if I&#39;m doi=
ng some calculations with the volume on my speakers, I may have an acceptab=
le range of 0 - 65,535.=A0 If my math comes up with a volume of 100,000, th=
en setting the volume to 65,535 may be reasonable.=A0 I don&#39;t know how =
often this kind of thing comes up though.<br>
<br>If you stick to &quot;drop-in&quot; replacements, then I&#39;m not sure=
 if there&#39;s any benefit to an &quot;ignore&quot; policy.=A0 Ignore is e=
quivalent to the raw type.=A0 Fixed-point libraries could make use of it th=
ough.=A0 Debug assertions aren&#39;t any better from a security standpoint,=
 but they could help discover bugs in non-security critical code.<br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--20cf303b433b02985804cf68dd8e--

.

------=_Part_85_5634945.1353951901093
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, November 25, 2012 11:17:04 PM UTC-8, viboes wrote:
>
>
>
>>  c) I considered a policy parameter of some sort to indicate how to
> handle overflows - they use an enum to select.  But I rejected the idea for
> two reasons
>
> i) more complexity with very little value.
> ii)  I couldn't see how to do it with something like
>
> safe<int32> x;
> safe<int16> y;
> safe<int32> z;
> z = x + y;  // where would the policy parameter go?
>
> With the Lawrence proposal you don't have overflow as far as you don't
> loss range. So the natural place is to use it only with assignment.
>

It's exactly the same with safe<T>.  EXCEPT the case where safe<int64> +
safe<int64> where there is not large type to hold the intermediate result.
That is, the overflow can occur before the assignment.  In this case, it
throws immediately.  I struggled on how to avoid this - but solutions
seemed more and more heavy weight.


> integral<31,OV1> x;
> integral<15,OV2> y;
> integral<31,OV3> z;
> z = x + y;
>
> Check for overflow only when doing the assignment using the overflow OV3
> policy.
>

I suppose this could be made to work - except for the note above.

>
> The fact to add the overflow policy on the type makes the code less weight.
>
> We can have also a base class for integral that has no overflow policy and
> forbids assignment that can loss information
>
> basic_integral<31> x;
> basic_integral<15> y;
> basic_integral<31> z;
> z = x + y; // compile file
>
>  The user will need to use a number_cast conversion like in
>
> z = number_cast<OV3>(x + y);
>

I wanted to avoid this so as to keep the "drop-in" replacement
functionality. I want people take a program with bugs in it,  change all
their "int" to safe<int>, etc. run the program and trap errors. This makes
the library much, much more attractive to use.


> But do the PO proposal or your Safe library allow to saturate on overflow,
> assert, ignore, ...?
>

The safe<T> throws an exception.  Users would have to trap the exception if
they want to handle it in some specific way.  I considered alternatives,
but I felt that if something traps it's almost always an unrecoverable
error - ie a programming error - so making it any fancier than necessary
would be counter productive - also refer to the note above regarding trying
to specify a policy.

The thread started with the proposal to consider SafeInt for inclusion in
the standard library.  safe<T> should be considered in this light.

Other proposals - modular arithmetic, decimal integers, etc should be
considered separately.

Note that safe<T> uses the traits defined in std::limits so that it should
be possible to apply safe<T> to any type which has std::limits<T>
implemented.  (I doubt it's possible now - but I believe it can be made to
work).  This would leave the concept of "safe" as orthogonal to the "number
type" which is also where I believe we would want to be.

Robert Ramey.

Robert Ramey


>
> Best,
> Vicente
>
>

--




------=_Part_85_5634945.1353951901093
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, November 25, 2012 11:17:04 PM UTC-8, viboes wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#00=
0000"><br>
 =20
   =20
 =20
  <blockquote type=3D"cite"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br></b=
lockquote></blockquote><blockquote type=3D"cite">
      <div>
        c) I considered a policy parameter of some sort to indicate how
        to handle overflows - they use an enum to select.&nbsp; But I
        rejected the idea for two reasons<br>
        <br>
        i) more complexity with very little value.<br>
        ii)&nbsp; I couldn't see how to do it with something like<br>
        <br>
        safe&lt;int32&gt; x;<br>
        safe&lt;int16&gt; y;<br>
        safe&lt;int32&gt; z;<br>
        z =3D x + y;&nbsp; // where would the policy parameter go?<br>
      </div>
    </blockquote>
    With the
   =20
    Lawrence proposal you don't have overflow as far as you don't loss
    range. So the natural place is to use it only with assignment.<br></div=
></blockquote><div><br>It's exactly the same with safe&lt;T&gt;.&nbsp; EXCE=
PT the case where safe&lt;int64&gt; + safe&lt;int64&gt; where there is not =
large type to hold the intermediate result. That is, the overflow can occur=
 before the assignment.&nbsp; In this case, it throws immediately.&nbsp; I =
struggled on how to avoid this - but solutions seemed more and more heavy w=
eight.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcol=
or=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div>integral&lt;31,OV1&gt; x;<br>
      integral&lt;15,OV2&gt; y;<br>
      integral&lt;31,OV3&gt; z;<br>
      z =3D x + y;<br>
      <br>
      Check for overflow only when doing the assignment using the
      overflow OV3 policy. <br></div></div></blockquote><div><br>I suppose =
this could be made to work - except for the note above. <br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#00000=
0"><div>
      <br>
      The fact to add the overflow policy on the type makes the code
      less weight.<br>
      <br>
      We can have also a base class for integral that has no overflow
      policy and forbids assignment that can loss information<br>
      <br>
      basic_integral&lt;31&gt; x;<br>
      basic_integral&lt;15&gt; y;<br>
      basic_integral&lt;31&gt; z;<br>
      z =3D x + y; // compile file<br>
      <br>
    </div>
    The user will need to use a number_cast conversion like in<br>
    <br>
    z =3D number_cast&lt;OV3&gt;(x + y);<br></div></blockquote><div><br>I w=
anted to avoid this so as to keep the "drop-in" replacement functionality. =
I want people take a program with bugs in it,&nbsp; change all their "int" =
to safe&lt;int&gt;, etc. run the program and trap errors. This makes the li=
brary much, much more attractive to use.<br></div><div>&nbsp;</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#0000=
00">But do the PO proposal or your
    Safe library allow to saturate on overflow, assert, ignore, ...?<br></d=
iv></blockquote><div><br>The safe&lt;T&gt; throws an exception.&nbsp; Users=
 would have to trap the exception if they want to handle it in some specifi=
c way.&nbsp; I considered alternatives, but I felt that if something traps =
it's almost always an unrecoverable error - ie a programming error - so mak=
ing it any fancier than necessary would be counter productive - also refer =
to the note above regarding trying to specify a policy.<br><br>The thread s=
tarted with the proposal to consider SafeInt for inclusion in the standard =
library.&nbsp; safe&lt;T&gt; should be considered in this light.<br><br>Oth=
er proposals - modular arithmetic, decimal integers, etc should be consider=
ed separately.<br><br>Note that safe&lt;T&gt; uses the traits defined in st=
d::limits so that it should be possible to apply safe&lt;T&gt; to any type =
which has std::limits&lt;T&gt; implemented.&nbsp; (I doubt it's possible no=
w - but I believe it can be made to work).&nbsp; This would leave the conce=
pt of "safe" as orthogonal to the "number type" which is also where I belie=
ve we would want to be.<br><br>Robert Ramey.<br><br>Robert Ramey<br>&nbsp;<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFF=
FF" text=3D"#000000">
    <br>
    Best,<br>
    Vicente <br>
    <br>
  </div>

</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_85_5634945.1353951901093--

.

------=_Part_230_33122499.1353952156965
Content-Type: text/plain; charset=ISO-8859-1



>
> I wanted to add. safe<T> could be defined as a alias of the fixed point
> class.
>

I would like to keep the "save" concept/idea orthogonal to the "numeric"
concept/idea.

Robert Ramey

>
> -- Vicente
>

--




------=_Part_230_33122499.1353952156965
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" t=
ext=3D"#000000">
    <br>
    I wanted to add. safe&lt;T&gt; could be defined as a alias of the
    fixed point class.<br></div></blockquote><div><br>I would like to keep =
the "save" concept/idea orthogonal to the "numeric" concept/idea.<br><br>Ro=
bert Ramey <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgco=
lor=3D"#FFFFFF" text=3D"#000000">
    <br>
    -- Vicente<br>
  </div>

</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_230_33122499.1353952156965--

.

------=_Part_79_22755793.1353952679143
Content-Type: text/plain; charset=ISO-8859-1



On Monday, November 26, 2012 8:59:59 AM UTC-8, Ben Craig wrote:
>
> Some large use cases for SafeInt are computing sizes for buffers and array
> indices.  In these situations, you probably want to throw an exception, or
> terminate the program.  Saturation, assertions in debug mode, and ignoring
> aren't very good options from a security standpoint.
>

agreed.  But note that SafeInt or safe<unsigned int> aren't that useful for
things like buffer sizes or array indices unless they happen to be exactly
max<unsigned int> long or something like that.

However, it turns out there is a very slick solution here.  When I started
this effort what I really wanted to make was "save_range<min, max> for just
this purpose.  I made this and since it depended upon std::limits, it could
use the equivalent of

template<T>
safe : public safe_range<std::limits<T>:min, safe_range<std::limits<T>:max>
{
};

to make safe<int> etc.

So to trap array and buffer overflows one would already have (for free)

char a[12345];
safe_unsigned_range<0, sizeof(a)> aindex;

and you're in business. It's actually a side effect of the way it's
implemented.
 .

> If you stick to "drop-in" replacements, then I'm not sure if there's any
> benefit to an "ignore" policy.  Ignore is equivalent to the raw type.


+1


> Fixed-point libraries could make use of it though.  Debug assertions
> aren't any better from a security standpoint, but they could help discover
> bugs in non-security critical code.
>

I would like to avoid "feature creep"

Robert Ramey


--




------=_Part_79_22755793.1353952679143
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, November 26, 2012 8:59:59 AM UTC-8, Ben Craig wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">Some large use cases for SafeInt a=
re computing sizes for buffers and array indices.&nbsp; In these situations=
, you probably want to throw an exception, or terminate the program.&nbsp; =
Saturation, assertions in debug mode, and ignoring aren't very good options=
 from a security standpoint.<br></blockquote><div><br>agreed.&nbsp; But not=
e that SafeInt or safe&lt;unsigned int&gt; aren't that useful for things li=
ke buffer sizes or array indices unless they happen to be exactly max&lt;un=
signed int&gt; long or something like that.<br><br>However, it turns out th=
ere is a very slick solution here.&nbsp; When I started this effort what I =
really wanted to make was "save_range&lt;min, max&gt; for just this purpose=
..&nbsp; I made this and since it depended upon std::limits, it could use th=
e equivalent of<br><br>template&lt;T&gt;<br>safe : public safe_range&lt;std=
::limits&lt;T&gt;:min, safe_range&lt;std::limits&lt;T&gt;:max&gt; {<br>};<b=
r><br>to make safe&lt;int&gt; etc.<br><br>So to trap array and buffer overf=
lows one would already have (for free)<br><br>char a[12345];<br>safe_unsign=
ed_range&lt;0, sizeof(a)&gt; aindex;<br><br>and you're in business. It's ac=
tually a side effect of the way it's implemented.<br>&nbsp;.<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">If you stick to "drop-in" replaceme=
nts, then I'm not sure if there's any benefit to an "ignore" policy.&nbsp; =
Ignore is equivalent to the raw type.&nbsp; </blockquote><div><br>+1<br>&nb=
sp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Fixed-point libra=
ries could make use of it though.&nbsp; Debug assertions aren't any better =
from a security standpoint, but they could help discover bugs in non-securi=
ty critical code.<br></blockquote><div><br>I would like to avoid "feature c=
reep"<br><br>Robert Ramey<br>&nbsp;<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_79_22755793.1353952679143--

.

On 11/23/12, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> On Nov 23, 2012 <robertmacleranramey@gmail.com> wrote:
> > On Thursday, November 22, 2012 6:10:24 PM UTC-8, Ben Craig wrote:
> > > That would likely turn into a fixed-point arithmetic
> > > <http://en.wikipedia.org/wiki/Fixed-point_arithmetic> library.
>
> I would rather say that a fixed-point library, as well as a
> rationals library, would be alongside (or maybe one level above)
> safe-int, as opposed to a generalization of it.

The committee has a Study Group 6 addressing issues of number
representation.  One of the tasks is figuring out the logical
relationships and implementation relationships between various
number types.

We welcome contributions.

> Both fixed_point<T> and rational<T> are useful as long as the
> values do not overflow. However, and this is particularly true in
> the case of rationals, there are several application domains where
> computations can easily, and often, overflow. In these cases, one
> must use a big_int (unlimited precision integer) as T (whether for
> a fixed_point or rational) But that is pessimistically inefficient,
> so one would consider a non-template "exact" numeric type which
> would have a dynamic internal representation of rational<T>
> but which would automatically switch from T to 2T (meaning a two
> times bigger integer), until it reaches big_int.

The study group has reached a tentative conclusion that a rational
should be based either on a bigint, or do rounding when the
representation is not sufficient for the true result.  The former
would be useful in computational geometry.  The latter would be
useful in music.

Fixed point is useful even in the presence of overflow, but the
method for dealing with the overflow may vary depending on the
application.  In these cases, I think it generally best to give
program the tools they need, rather than pick a single solution.
(Plain unsigned ints picked one solution, and it is inappropriate
in a number of cases.)

--
Lawrence Crowl

--




.

On 11/25/12, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> Le 25/11/12 23:07, robertmacleranramey@gmail.com a =E9crit :
> > On Sunday, November 25, 2012 1:39:58 PM UTC-8, viboes wrote:
> > > Le 08/11/12 03:59, Ben Craig a =E9crit :
> > > > have you take a look at "C++ Binary Fixed-Point Arithmetic"
> > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html
> > > > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html=
>?
> > > >
> > > > It seems to respond to most of the problems (if not all)
> > > > you try to solve.
> > > >
> > > > Could you comment features you want that this proposal
> > > > doesn't covers?
> >
> > Very interesting.  i don't know whether or not I saw this when
> > I made my version of safe<T>.
>
> My question was addressed to the PO. Anyway ...
>
> > In general, I see it as very similar.  But there are some
> > notable differences.
> >
> > "The fixed-point library contains four class templates. They
> > are |cardinal| and |integral| for integer arithmetic, and
> > |nonnegative| and |negatable| for fractional arithmetic."
> >
> > a) I use the integer traits defined by std::limits<T> to
> > determined whether the type is signed/unsigned, the max/min,
> > etc. So instead of having a variety of templates, there is only
> > one using TMP to determine the traits.
>
> I don't see an added value at the user level. I'm open to
> variations.

I am the author of that proposal.  The difference is that my proposal
is parameterized by the number of bits, not by a representation type.
The implementation is responsible for picking a representation
suitable to the number of bits and the sign.  So, in my proposal,
there is no type parameter available to extract that the information.

> > b) I don't address fractions or rounding at all.
>
> Well, this is out of the PO subject, so no matter. I could
> understand that we could want safe integers independently.
>
> > c) I considered a policy parameter of some sort to indicate
> > how to handle overflows - they use an enum to select.  But I
> > rejected the idea for two reasons
> >
> > i) more complexity with very little value.
> > ii)  I couldn't see how to do it with something like
> >
> > safe<int32> x;
> > safe<int16> y;
> > safe<int32> z;
> > z =3D x + y;  // where would the policy parameter go?
>
> With the Lawrence proposal you don't have overflow as far as
> you don't loss range. So the natural place is to use it only
> with assignment.
>
> integral<31,OV1> x;
> integral<15,OV2> y;
> integral<31,OV3> z;
> z =3D x + y;
>
> Check for overflow only when doing the assignment using the
> overflow OV3 policy.
>
> The fact to add the overflow policy on the type makes the code
> less weight.
>
> We can have also a base class for integral that has no overflow
> policy and forbids assignment that can loss information
>
> basic_integral<31> x;
> basic_integral<15> y;
> basic_integral<31> z;
> z =3D x + y; // compile file
>
> The user will need to use a number_cast conversion like in
>
> z =3D number_cast<OV3>(x + y);

That was part of the feedback from the committee's first review
of the proposal.

> > In the end, I re-focused on a drop-in replacement for all integer
> > types.  "all integer types" means all types - instrinsic and user
> > defined types for which std::limit<T>::is_integer() return true.
> >
> > To summarize, SafeInt and safe<T> are different than the proposal
> > in the paper above.  But I believe they are better.
>
> Humm, I need then to read both ;-) But do the PO proposal or your
> Safe library allow to saturate on overflow, assert, ignore, ...?

A safe integer proposal and my fixed-point proposal do serve
different purposes.  My proposal works best when the range and
precision is derivable from the data, e.g. pixel values.  A safe
integer type works best when the range is derivable from the machine,
e.g. indexing.

So, I think there is room for a safe integer proposal.  I would,
however, like to see in conceptually integrated with my proposal
so that we have one mechanism for specifying overflow behavior, etc.

--=20
Lawrence Crowl

--=20




.

On 11/26/12, Ben Craig <ben.craig@gmail.com> wrote:
> Some large use cases for SafeInt are computing sizes for buffers
> and array indices.  In these situations, you probably want
> to throw an exception, or terminate the program.  Saturation,
> assertions in debug mode, and ignoring aren't very good options
> from a security standpoint.

Not necessarily true.  An exception could be vulnerable to a
denial-of-service attack, where as saturation may just deliver
fewer widgets than desired.

> Are the saturate, debug assert, and ignore cases useful in some
> other domain?  I can see some use for saturation in some cases
> where a (possibly implicit) range check was already present.
> For instance, if I'm doing some calculations with the volume
> on my speakers, I may have an acceptable range of 0 - 65,535.
> If my math comes up with a volume of 100,000, then setting the
> volume to 65,535 may be reasonable.  I don't know how often this
> kind of thing comes up though.

It comes up often in signal processing applications.  The C standard
has an option for fixed-point arithmetic, and it allow saturated
arithmetic for exactly this reason.

> If you stick to "drop-in" replacements, then I'm not sure if
> there's any benefit to an "ignore" policy.  Ignore is equivalent to
> the raw type.  Fixed-point libraries could make use of it though.
> Debug assertions aren't any better from a security standpoint,
> but they could help discover bugs in non-security critical code.

Can we be clear on what "ignore" means?  I have two policies in mind,
both of which allow the implementation to ignore overflow.

"I have done a mathematical proof that overflow cannot occur.
Code reviewers please check my proof."

"I have really low reliability constraints, and do not have the need
or time to make the code correct in all circumstances.  Don't bother
me with overflow."

--
Lawrence Crowl

--




.

On 11/26/12, robertmacleranramey@gmail.com
<robertmacleranramey@gmail.com> wrote:
> On Sunday, November 25, 2012 11:17:04 PM UTC-8, viboes wrote:
> > > c) I considered a policy parameter of some sort to indicate
> > > how to handle overflows - they use an enum to select.  But I
> > > rejected the idea for two reasons
> > >
> > > i) more complexity with very little value.
> > > ii)  I couldn't see how to do it with something like
> > >
> > > safe<int32> x;
> > > safe<int16> y;
> > > safe<int32> z;
> > > z = x + y;  // where would the policy parameter go?
> >
> > With the Lawrence proposal you don't have overflow as far as
> > you don't loss range. So the natural place is to use it only
> > with assignment.
>
> It's exactly the same with safe<T>.  EXCEPT the case where
> safe<int64> + safe<int64> where there is not large type to
> hold the intermediate result.  That is, the overflow can occur
> before the assignment.  In this case, it throws immediately.
> I struggled on how to avoid this - but solutions seemed more and
> more heavy weight.

Given that expressions can have an arbitrary number of operators,
how do you handle other intermediate results that might overflow?

> > integral<31,OV1> x;
> > integral<15,OV2> y;
> > integral<31,OV3> z;
> > z = x + y;
> >
> > Check for overflow only when doing the assignment using the
> > overflow OV3 policy.
>
> I suppose this could be made to work - except for the note above.

The intent in the fixed-point library is that the intermediate type
would switch to a multi-precision implementation.  An alternative
is cause a compilation error.

> > The fact to add the overflow policy on the type makes the code
> > less weight.
> >
> > We can have also a base class for integral that has no overflow
> > policy and forbids assignment that can loss information
> >
> > basic_integral<31> x;
> > basic_integral<15> y;
> > basic_integral<31> z;
> > z = x + y; // compile file
> >
> > The user will need to use a number_cast conversion like in
> >
> > z = number_cast<OV3>(x + y);
>
> I wanted to avoid this so as to keep the "drop-in" replacement
> functionality. I want people take a program with bugs in it,
> change all their "int" to safe<int>, etc. run the program and trap
> errors. This makes the library much, much more attractive to use.

I agree that this approach will produce a valuable tool.

> > But do the PO proposal or your Safe library allow to saturate
> > on overflow, assert, ignore, ...?
>
> The safe<T> throws an exception.  Users would have to trap
> the exception if they want to handle it in some specific way.
> I considered alternatives, but I felt that if something traps it's
> almost always an unrecoverable error - ie a programming error - so
> making it any fancier than necessary would be counter productive -
> also refer to the note above regarding trying to specify a policy.
>
> The thread started with the proposal to consider SafeInt for
> inclusion in the standard library.  safe<T> should be considered
> in this light.
>
> Other proposals - modular arithmetic, decimal integers, etc should
> be considered separately.

I agree that a safe-int proposal make sense, but we want the proposal
to integrate with the language and library as a whole.  We have a
study group to avoid unintended incompatibilities within the C++
library.  So, all these proposals should be considered together.

> Note that safe<T> uses the traits defined in std::limits so that
> it should be possible to apply safe<T> to any type which has
> std::limits<T> implemented.  (I doubt it's possible now - but I
> believe it can be made to work).  This would leave the concept of
> "safe" as orthogonal to the "number type" which is also where I
> believe we would want to be.

I have less confidence that we can have one definition of "safe",
let alone apply it uniformly to all numbers.

--
Lawrence Crowl

--




.

This is a multi-part message in MIME format.
--------------080500050302050205010407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 23/11/12 18:10, robertmacleranramey@gmail.com a =E9crit :
>
>
> On Friday, November 23, 2012 4:26:08 AM UTC-8, Fernando Cacciola wrote:
>
>
>     On Fri, Nov 23, 2012 at 3:45 AM, <robertmac...@gmail.com
>     <javascript:>> wrote:
>
>
>
>         On Thursday, November 22, 2012 6:10:24 PM UTC-8, Ben Craig wrote:
>
>
>
>             That would likely turn into a fixed-point arithmetic
>             <http://en.wikipedia.org/wiki/Fixed-point_arithmetic> library=
..
>
>
>
>     I would rather say that a fixed-point library, as well as a
>     rationals library, would be alongside (or maybe one level above)
>     safe-int, as opposed to a generalization of it.
>
>
>
> I'm not sure I followed your suggestion, but somehow I'm thinking I=20
> might be in agreement. My view would be the "safe" idea would be=20
> orthogonal to the "numeric" idea.  So
>
> int, rational<T>, multiprecision<N>, .... would have std limits<T>=20
> defined. std::limits includes members to define min/max values and a=20
> lot of other features of numeric types.
>
> This would make them fullfill the "Numeric" concept (type requirements).
>
> safe<T> would be defined for any type T fullfilling the "Numeric" concept=
..
safe and integers could be orthogonal, but I don't see how a safe<T>=20
class could provide safety to rational as overflow is avoided by using=20
gcd while doing the addition of two rationals and many other tricks.

> and safe<T> would also have std::limits implemented so it would=20
> fullfill the "Numeric" concept as well.
>
> This would separate the "safe" idea from the "numeric" idea and permit=20
> users to use the "safe" version if and only if actually desired.  It=20
> would also clarify what "safe" does as opposed to what "numeric"=20
> does.  My proposal implements this idea for current integer types.
So maybe your class should be renamed as safe_int ;-)

> It hasn't really been investigated whether this extends well to all=20
> integer types for which std::limits is implemented. Anyway, this is=20
> far into the future.
>

I guess you meant any number type.

-- Vicente

--=20




--------------080500050302050205010407
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 23/11/12 18:10,
      <a class="moz-txt-link-abbreviated" href="mailto:robertmacleranramey@gmail.com">robertmacleranramey@gmail.com</a> a &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite="mid:c9e1b936-7cac-4bc3-9e78-0a3c3bf803e3@isocpp.org"
      type="cite"><br>
      <br>
      On Friday, November 23, 2012 4:26:08 AM UTC-8, Fernando Cacciola
      wrote:
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <div><br>
          <div class="gmail_quote">On Fri, Nov 23, 2012 at 3:45 AM, <span
              dir="ltr">&lt;<a moz-do-not-send="true" href="javascript:"
                target="_blank" gdf-obfuscated-mailto="0-HkoyxGrxwJ">robertmac...@gmail.com</a><wbr>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div><br>
                <br>
                On Thursday, November 22, 2012 6:10:24 PM UTC-8, Ben
                Craig wrote:
                <blockquote class="gmail_quote" style="margin:0px 0px
                  0px 0.8ex;border-left:1px solid
                  rgb(204,204,204);padding-left:1ex">
                  <br>
                  <div>&nbsp;<br>
                    That would likely turn into a <a
                      moz-do-not-send="true"
                      href="http://en.wikipedia.org/wiki/Fixed-point_arithmetic"
                      target="_blank">fixed-point arithmetic</a>
                    library.<br>
                  </div>
                </blockquote>
              </div>
              <div><br>
              </div>
            </blockquote>
            <div><br>
              I would rather say that a fixed-point library, as well as
              a rationals library, would be alongside (or maybe one
              level above) safe-int, as opposed to a generalization of
              it.<br>
            </div>
          </div>
        </div>
      </blockquote>
      <div><br>
        <br>
        I'm not sure I followed your suggestion, but somehow I'm
        thinking I might be in agreement. My view would be the "safe"
        idea would be orthogonal to the "numeric" idea.&nbsp; So<br>
        <br>
        int, rational&lt;T&gt;, multiprecision&lt;N&gt;, .... would have
        std limits&lt;T&gt; defined. std::limits includes members to
        define min/max values and a lot of other features of numeric
        types.<br>
        <br>
        This would make them fullfill the "Numeric" concept (type
        requirements).<br>
        <br>
        safe&lt;T&gt; would be defined for any type T fullfilling the
        "Numeric" concept.<br>
      </div>
    </blockquote>
    safe and integers could be orthogonal, but I don't see how a
    safe&lt;T&gt; class could provide safety to rational as overflow is
    avoided by using gcd while doing the addition of two rationals and
    many other tricks.<br>
    <br>
    <blockquote
      cite="mid:c9e1b936-7cac-4bc3-9e78-0a3c3bf803e3@isocpp.org"
      type="cite">
      <div>and safe&lt;T&gt; would also have std::limits implemented so
        it would fullfill the "Numeric" concept as well.<br>
        <br>
        This would separate the "safe" idea from the "numeric" idea and
        permit users to use the "safe" version if and only if actually
        desired.&nbsp; It would also clarify what "safe" does as opposed to
        what "numeric" does.&nbsp; My proposal implements this idea for
        current integer types.&nbsp; </div>
    </blockquote>
    So maybe your class should be renamed as safe_int ;-)<br>
    <br>
    <blockquote
      cite="mid:c9e1b936-7cac-4bc3-9e78-0a3c3bf803e3@isocpp.org"
      type="cite">
      <div>It hasn't really been investigated whether this extends well
        to all integer types for which std::limits is implemented.&nbsp;
        Anyway, this is far into the future.<br>
        <br>
      </div>
    </blockquote>
    <br>
    I guess you meant any number type.<br>
    <br>
    -- Vicente<br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--------------080500050302050205010407--

.

------=_Part_1309_27114948.1353982614483
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Monday, November 26, 2012 3:32:09 PM UTC-8, viboes wrote:
>
>  Le 23/11/12 18:10, robertmac...@gmail.com <javascript:> a =E9crit :safe=
=20
> and integers could be orthogonal, but I don't see how a safe<T> class cou=
ld=20
> provide safety to rational as overflow is avoided by using gcd while doin=
g=20
> the addition of two rationals and many other tricks.
>

then safe<rational> wouldn't throw on overflow - because it can't happen. =
=20
Same with save<multi-precision>.  But currently safe<T> throws on at=20
attempt to divide by zero.  So the concept is easily extended to other=20
numeric types.  I can easily imagine a safe<float> and safe<double> which=
=20
could overflow, underflow and device by zero.  Basically safe<T> would=20
throw anytime and operation on T doesn't yield the expected mathematical=20
result.

Note that I'm getting ahead of myself here.  safe<T> is only implemented=20
for types which are integers according to std::limits<T>.  For other types=
=20
it will trip a compile time assert.
=20

>
> Robert Ramey
>

--=20




------=_Part_1309_27114948.1353982614483
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, November 26, 2012 3:32:09 PM UTC-8, viboes wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 23/11/12 18:10,
      <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"rP=
LY3l9TfcYJ">robertmac...@gmail.com</a> a =E9crit&nbsp;:safe and integers co=
uld be orthogonal, but I don't see how a
    safe&lt;T&gt; class could provide safety to rational as overflow is
    avoided by using gcd while doing the addition of two rationals and
    many other tricks.<br></div></div></blockquote><div><br>then safe&lt;ra=
tional&gt; wouldn't throw on overflow - because it can't happen.&nbsp; Same=
 with save&lt;multi-precision&gt;.&nbsp; But currently safe&lt;T&gt; throws=
 on at attempt to divide by zero.&nbsp; So the concept is easily extended t=
o other numeric types.&nbsp; I can easily imagine a safe&lt;float&gt; and s=
afe&lt;double&gt; which could overflow, underflow and device by zero.&nbsp;=
 Basically safe&lt;T&gt; would throw anytime and operation on T doesn't yie=
ld the expected mathematical result.<br><br>Note that I'm getting ahead of =
myself here.&nbsp; safe&lt;T&gt; is only implemented for types which are in=
tegers according to std::limits&lt;T&gt;.&nbsp; For other types it will tri=
p a compile time assert.<br>&nbsp;<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div><br>Robert Ramey<br> </div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1309_27114948.1353982614483--

.

--047d7b34372cf841a504cf79fd81
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Nov 25, 2012 at 6:39 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

>  Le 08/11/12 03:59, Ben Craig a =E9crit :
>
> SafeInt information can be found here <http://safeint.codeplex.com/>.
> Basically, it is an open source library authored by security expert David
> LeBlanc of Microsoft.  It is basically a "drop-in" replacement for intege=
r
> types, and will throw an exception whenever integer overflows occur.  I
> believe that getting this added to the standard would be a boon to C++ an=
d
> secure code.  It should be a relatively low effort addition considering t=
he
> "proof-of-concept" is already widely used within Microsoft.
> --
>
>
>
>
> Hi,
>
> have you take a look at "C++ Binary Fixed-Point Arithmetic"
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html?
>

I've been wanting to read that proposal, but never did before.

It looks to me that it is a very good proposal BTW



--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=20




--047d7b34372cf841a504cf79fd81
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Nov 25, 2=
012 at 6:39 PM, Vicente J. Botet Escriba <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr<=
/a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 08/11/12 03:59, Ben Craig a =E9crit=A0:<br>
    </div><div class=3D"im">
    <blockquote type=3D"cite">SafeInt information can be found <a href=3D"h=
ttp://safeint.codeplex.com/" target=3D"_blank">here</a>.=A0
      Basically, it is an open source library authored by security
      expert David LeBlanc of Microsoft.=A0 It is basically a &quot;drop-in=
&quot;
      replacement for integer types, and will throw an exception
      whenever integer overflows occur.=A0 I believe that getting this
      added to the standard would be a boon to C++ and secure code.=A0 It
      should be a relatively low effort addition considering the
      &quot;proof-of-concept&quot; is already widely used within Microsoft.=
<br>
      -- <br>
      =A0<br>
      =A0<br>
      =A0<br>
    </blockquote></div>
    Hi,<br>
    <br>
    have you take a look at &quot;C++ Binary Fixed-Point Arithmetic&quot;
    <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n335=
2.html" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2012/n3352.html</a>?<br></div></blockquote><div><br>I&#39;ve been wanting=
 to read that proposal, but never did before.<br>

<br>It looks to me that it is a very good proposal BTW<span class=3D"HOEnZb=
"><font color=3D"#888888">=A0
<br>
</font></span></div></div><br><br clear=3D"all"><br>-- <br>Fernando Cacciol=
a<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consultin=
g.com">http://www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b34372cf841a504cf79fd81--

.

--047d7b34372cd161ce04cf7a1543
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 26, 2012 at 1:59 PM, Ben Craig <ben.craig@gmail.com> wrote:

> Some large use cases for SafeInt are computing sizes for buffers and array
> indices.


Hmmm.
Can you elaborate how is SafeInt safe when it comes to an array index in
the case of an array of runtime size? Which I believe is, by far, the most
common type of array (buffer, container, etc)

For *that* purpose I think the proper tool is an integer with runtime
boundaries (a number of these have been implemented and proposed to, for
instance, Boost)



>   In these situations, you probably want to throw an exception, or
> terminate the program.


This s off-topic but IMO you never ever want to terminate a program when
you use a language that supports exceptions, like C++



> Saturation, assertions in debug mode, and ignoring aren't very good
> options from a security standpoint.
>
>
Maybe. It depends on how you define security.
But for sure those are good options in several application domains, and a
standard C++ library facility should consider them all (as much as possible)


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b34372cd161ce04cf7a1543
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Nov 26, 2=
012 at 1:59 PM, Ben Craig <span dir=3D"ltr">&lt;<a href=3D"mailto:ben.craig=
@gmail.com" target=3D"_blank">ben.craig@gmail.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

Some large use cases for SafeInt are computing sizes for buffers and array =
indices.</blockquote><div><br>Hmmm.<br>Can you elaborate how is SafeInt saf=
e when it comes to an array index in the case of an array of runtime size? =
Which I believe is, by far, the most common type of array (buffer, containe=
r, etc)<br>

<br>For *that* purpose I think the proper tool is an integer with runtime b=
oundaries (a number of these have been implemented and proposed to, for ins=
tance, Boost)<br><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

=A0 In these situations, you probably want to throw an exception, or termin=
ate the program.=A0</blockquote><div><br>This s off-topic but IMO you never=
 ever want to terminate a program when you use a language that supports exc=
eptions, like C++<br>

<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"> Saturation, assertions in debu=
g mode, and ignoring aren&#39;t very good options from a security standpoin=
t.<br>


<br></blockquote><div><br>Maybe. It depends on how you define security.<br>=
But for sure those are good options in several application domains, and a s=
tandard C++ library facility should consider them all (as much as possible)=
<br>

=A0<br></div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Foun=
der<br><a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-con=
sulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b34372cd161ce04cf7a1543--

.

--047d7b34372c8925bb04cf7a4040
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 26, 2012 at 2:45 PM, <robertmacleranramey@gmail.com> wrote:

>
>
> On Sunday, November 25, 2012 11:17:04 PM UTC-8, viboes wrote:
>>
>>
>>
>>>  c) I considered a policy parameter of some sort to indicate how to
>> handle overflows - they use an enum to select.  But I rejected the idea for
>> two reasons
>>
>> i) more complexity with very little value.
>> ii)  I couldn't see how to do it with something like
>>
>> safe<int32> x;
>> safe<int16> y;
>> safe<int32> z;
>> z = x + y;  // where would the policy parameter go?
>>
>> With the Lawrence proposal you don't have overflow as far as you don't
>> loss range. So the natural place is to use it only with assignment.
>>
>
> It's exactly the same with safe<T>.  EXCEPT the case where safe<int64> +
> safe<int64> where there is not large type to hold the intermediate result.
> That is, the overflow can occur before the assignment.  In this case, it
> throws immediately.  I struggled on how to avoid this - but solutions
> seemed more and more heavy weight.
>
> Hmm, how isn't is as simple as using a software-based int128 number type?


>
>> integral<31,OV1> x;
>> integral<15,OV2> y;
>> integral<31,OV3> z;
>> z = x + y;
>>
>> Check for overflow only when doing the assignment using the overflow OV3
>> policy.
>>
>
> I suppose this could be made to work - except for the note above.
>
>>
>> The fact to add the overflow policy on the type makes the code less
>> weight.
>>
>> We can have also a base class for integral that has no overflow policy
>> and forbids assignment that can loss information
>>
>> basic_integral<31> x;
>> basic_integral<15> y;
>> basic_integral<31> z;
>> z = x + y; // compile file
>>
>>  The user will need to use a number_cast conversion like in
>>
>> z = number_cast<OV3>(x + y);
>>
>
> I wanted to avoid this so as to keep the "drop-in" replacement
> functionality. I want people take a program with bugs in it,  change all
> their "int" to safe<int>, etc. run the program and trap errors.
>

Imagine you have a program and you get a division by zero exception . What
do you do
You change the program so that, instead of attempting a computation that
cannot be performed, it determines the case and handle the "exceptional
case" manually in a different way.
You could just let the exception abort the current execution block but
that's NOT the way division by zero is handled.

Now suppose you change all the 'int' for safe<int> and you discover a point
where overflow is occurring?  What do you do?
By analogy to the div-by-zero case, and IME (and I do have experience
writing algorithms that need handle overflow, both integer and
floating-point), you also want to detect the case before-hand so you can do
something else.
Simply changing a program so that instead of UB it throws is a step ahead,
but it's a too general solution that surely works for general application
code. But if you are writing a numerical algorithm OTOH you need, for
example, to have a clean and simple way to handle the overflow and do
something else *without* aborting the computation.



>
>
>> But do the PO proposal or your Safe library allow to saturate on
>> overflow, assert, ignore, ...?
>>
>
> The safe<T> throws an exception.  Users would have to trap the exception
> if they want to handle it in some specific way.  I considered alternatives,
> but I felt that if something traps it's almost always an unrecoverable
> error - ie a programming error
>

Wait.
Numerical overflow is *rarely* a programming error. It's the consequence of
finite precision when crunching numbers.


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b34372c8925bb04cf7a4040
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Nov 26, 2=
012 at 2:45 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:robertmacleranrame=
y@gmail.com" target=3D"_blank">robertmacleranramey@gmail.com</a>&gt;</span>=
 wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br><br>On Sunday, Novembe=
r 25, 2012 11:17:04 PM UTC-8, viboes wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">

<div bgcolor=3D"#FFFFFF" text=3D"#000000"><br>
 =20
   =20
 =20
  <blockquote type=3D"cite"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br></b=
lockquote></blockquote><blockquote type=3D"cite">
      <div>
        c) I considered a policy parameter of some sort to indicate how
        to handle overflows - they use an enum to select.=A0 But I
        rejected the idea for two reasons<br>
        <br>
        i) more complexity with very little value.<br>
        ii)=A0 I couldn&#39;t see how to do it with something like<br>
        <br>
        safe&lt;int32&gt; x;<br>
        safe&lt;int16&gt; y;<br>
        safe&lt;int32&gt; z;<br>
        z =3D x + y;=A0 // where would the policy parameter go?<br>
      </div>
    </blockquote>
    With the
   =20
    Lawrence proposal you don&#39;t have overflow as far as you don&#39;t l=
oss
    range. So the natural place is to use it only with assignment.<br></div=
></blockquote></div><div><br>It&#39;s exactly the same with safe&lt;T&gt;.=
=A0 EXCEPT the case where safe&lt;int64&gt; + safe&lt;int64&gt; where there=
 is not large type to hold the intermediate result. That is, the overflow c=
an occur before the assignment.=A0 In this case, it throws immediately.=A0 =
I struggled on how to avoid this - but solutions seemed more and more heavy=
 weight.<br>

<br></div></blockquote><div>Hmm, how isn&#39;t is as simple as using a soft=
ware-based int128 number type?<br>=A0<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">

<div></div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div b=
gcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div>integral&lt;31,OV1&gt; x;<br>
      integral&lt;15,OV2&gt; y;<br>
      integral&lt;31,OV3&gt; z;<br>
      z =3D x + y;<br>
      <br>
      Check for overflow only when doing the assignment using the
      overflow OV3 policy. <br></div></div></blockquote></div><div><br>I su=
ppose this could be made to work - except for the note above. <br></div><di=
v class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div>
      <br>
      The fact to add the overflow policy on the type makes the code
      less weight.<br>
      <br>
      We can have also a base class for integral that has no overflow
      policy and forbids assignment that can loss information<br>
      <br>
      basic_integral&lt;31&gt; x;<br>
      basic_integral&lt;15&gt; y;<br>
      basic_integral&lt;31&gt; z;<br>
      z =3D x + y; // compile file<br>
      <br>
    </div>
    The user will need to use a number_cast conversion like in<br>
    <br>
    z =3D number_cast&lt;OV3&gt;(x + y);<br></div></blockquote></div><div><=
br>I wanted to avoid this so as to keep the &quot;drop-in&quot; replacement=
 functionality. I want people take a program with bugs in it,=A0 change all=
 their &quot;int&quot; to safe&lt;int&gt;, etc. run the program and trap er=
rors. </div>

</blockquote><div><br>Imagine you have a program and you get a division by =
zero exception . What do you do<br>You change the program so that, instead =
of attempting a computation that cannot be performed, it determines the cas=
e and handle the &quot;exceptional case&quot; manually in a different way.<=
br>

You could just let the exception abort the current execution block but that=
&#39;s NOT the way division by zero is handled.<br><br>Now suppose you chan=
ge all the &#39;int&#39; for safe&lt;int&gt; and you discover a point where=
 overflow is occurring?=A0 What do you do?<br>

By analogy to the div-by-zero case, and IME (and I do have experience writi=
ng algorithms that need handle overflow, both integer and floating-point), =
you also want to detect the case before-hand so you can do something else. =
<br>

Simply changing a program so that instead of UB it throws is a step ahead, =
but it&#39;s a too general solution that surely works for general applicati=
on code. But if you are writing a numerical algorithm OTOH you need, for ex=
ample, to have a clean and simple way to handle the overflow and do somethi=
ng else *without* aborting the computation.<br>

<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div></div><div class=3D"im"><d=
iv>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

<div bgcolor=3D"#FFFFFF" text=3D"#000000">But do the PO proposal or your
    Safe library allow to saturate on overflow, assert, ignore, ...?<br></d=
iv></blockquote></div><div><br>The safe&lt;T&gt; throws an exception.=A0 Us=
ers would have to trap the exception if they want to handle it in some spec=
ific way.=A0 I considered alternatives, but I felt that if something traps =
it&#39;s almost always an unrecoverable error - ie a programming error </di=
v>

</blockquote><div><br>Wait.<br>Numerical overflow is *rarely* a programming=
 error. It&#39;s the consequence of finite precision when crunching numbers=
..<br><br></div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Fo=
under<br>

<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b34372c8925bb04cf7a4040--

.

--047d7b34372c23d87d04cf7a57fa
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 26, 2012 at 7:59 PM, Lawrence Crowl <crowl@googlers.com> wrote:

> On 11/23/12, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> > On Nov 23, 2012 <robertmacleranramey@gmail.com> wrote:
> > > On Thursday, November 22, 2012 6:10:24 PM UTC-8, Ben Craig wrote:
> > > > That would likely turn into a fixed-point arithmetic
> > > > <http://en.wikipedia.org/wiki/Fixed-point_arithmetic> library.
> >
> > I would rather say that a fixed-point library, as well as a
> > rationals library, would be alongside (or maybe one level above)
> > safe-int, as opposed to a generalization of it.
>
> The committee has a Study Group 6 addressing issues of number
> representation.  One of the tasks is figuring out the logical
> relationships and implementation relationships between various
> number types.
>
> We welcome contributions.
>
> How do I join Study Group 6 ?

I would very much like to contribute.


>  > Both fixed_point<T> and rational<T> are useful as long as the
> > values do not overflow. However, and this is particularly true in
> > the case of rationals, there are several application domains where
> > computations can easily, and often, overflow. In these cases, one
> > must use a big_int (unlimited precision integer) as T (whether for
> > a fixed_point or rational) But that is pessimistically inefficient,
> > so one would consider a non-template "exact" numeric type which
> > would have a dynamic internal representation of rational<T>
> > but which would automatically switch from T to 2T (meaning a two
> > times bigger integer), until it reaches big_int.
>
> The study group has reached a tentative conclusion that a rational
> should be based either on a bigint, or do rounding when the
> representation is not sufficient for the true result.  The former
> would be useful in computational geometry.  The latter would be
> useful in music.
>
> I agree. Well almost.
There are significant efficiency concerns when using bigint, and I think
that in C++  it's possible to overcome that by means of a mechanism that
promotes to "the next most efficient integer type needed" as computations
are performed.
Something of this form has been done, sort of manually, over the past
decade or more, in different unrelated projects, and it would be fantastic
to capture some of that within standard C++


Fixed point is useful even in the presence of overflow, but the
> method for dealing with the overflow may vary depending on the
> application.  In these cases, I think it generally best to give
> program the tools they need, rather than pick a single solution.
> (Plain unsigned ints picked one solution, and it is inappropriate
> in a number of cases.)
>
> Agreed.


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b34372c23d87d04cf7a57fa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, Nov 26, 2012 =
at 7:59 PM, Lawrence Crowl <span dir=3D"ltr">&lt;<a href=3D"mailto:crowl@go=
oglers.com" target=3D"_blank">crowl@googlers.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

On 11/23/12, Fernando Cacciola &lt;<a href=3D"mailto:fernando.cacciola@gmai=
l.com">fernando.cacciola@gmail.com</a>&gt; wrote:<br>
<div class=3D"im">&gt; On Nov 23, 2012 &lt;<a href=3D"mailto:robertmacleran=
ramey@gmail.com">robertmacleranramey@gmail.com</a>&gt; wrote:<br>
&gt; &gt; On Thursday, November 22, 2012 6:10:24 PM UTC-8, Ben Craig wrote:=
<br>
&gt; &gt; &gt; That would likely turn into a fixed-point arithmetic<br>
</div>&gt; &gt; &gt; &lt;<a href=3D"http://en.wikipedia.org/wiki/Fixed-poin=
t_arithmetic" target=3D"_blank">http://en.wikipedia.org/wiki/Fixed-point_ar=
ithmetic</a>&gt; library.<br>
<div class=3D"im">&gt;<br>
&gt; I would rather say that a fixed-point library, as well as a<br>
&gt; rationals library, would be alongside (or maybe one level above)<br>
&gt; safe-int, as opposed to a generalization of it.<br>
<br>
</div>The committee has a Study Group 6 addressing issues of number<br>
representation. =A0One of the tasks is figuring out the logical<br>
relationships and implementation relationships between various<br>
number types.<br>
<br>
We welcome contributions.<br>
<div class=3D"im"><br></div></blockquote><div>How do I join Study Group 6 ?=
<br><br>I would very much like to contribute.<br>=A0<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">

<div class=3D"im">
&gt; Both fixed_point&lt;T&gt; and rational&lt;T&gt; are useful as long as =
the<br>
&gt; values do not overflow. However, and this is particularly true in<br>
&gt; the case of rationals, there are several application domains where<br>
&gt; computations can easily, and often, overflow. In these cases, one<br>
&gt; must use a big_int (unlimited precision integer) as T (whether for<br>
&gt; a fixed_point or rational) But that is pessimistically inefficient,<br=
>
&gt; so one would consider a non-template &quot;exact&quot; numeric type wh=
ich<br>
&gt; would have a dynamic internal representation of rational&lt;T&gt;<br>
&gt; but which would automatically switch from T to 2T (meaning a two<br>
&gt; times bigger integer), until it reaches big_int.<br>
<br>
</div>The study group has reached a tentative conclusion that a rational<br=
>
should be based either on a bigint, or do rounding when the<br>
representation is not sufficient for the true result. =A0The former<br>
would be useful in computational geometry. =A0The latter would be<br>
useful in music.<br>
<br></blockquote><div>I agree. Well almost.<br>There are significant effici=
ency concerns when using bigint, and I think that in C++=A0 it&#39;s possib=
le to overcome that by means of a mechanism that promotes to &quot;the next=
 most efficient integer type needed&quot; as computations are performed.<br=
>

Something of this form has been done, sort of manually, over the past decad=
e or more, in different unrelated projects, and it would be fantastic to ca=
pture some of that within standard C++<br><br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">


Fixed point is useful even in the presence of overflow, but the<br>
method for dealing with the overflow may vary depending on the<br>
application. =A0In these cases, I think it generally best to give<br>
program the tools they need, rather than pick a single solution.<br>
(Plain unsigned ints picked one solution, and it is inappropriate<br>
in a number of cases.)<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div>Agreed.<br></div></div><br clear=3D"all"><br>-- <br>Fernando Caccio=
la<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consulti=
ng.com">http://www.scisoft-consulting.com</a><br>


</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b34372c23d87d04cf7a57fa--

.

--20cf3011dc13766a9704cf7b3a53
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 27, 2012 at 7:32 AM, Fernando Cacciola <
fernando.cacciola@gmail.com> wrote:

>
> On Mon, Nov 26, 2012 at 1:59 PM, Ben Craig <ben.craig@gmail.com> wrote:
>
>> Some large use cases for SafeInt are computing sizes for buffers and
>> array indices.
>
>
> Hmmm.
> Can you elaborate how is SafeInt safe when it comes to an array index in
> the case of an array of runtime size? Which I believe is, by far, the most
> common type of array (buffer, container, etc)
>
> For *that* purpose I think the proper tool is an integer with runtime
> boundaries (a number of these have been implemented and proposed to, for
> instance, Boost)
>

Without a facility like SafeInt, a developer would likely write (buggy)
code like this:
size_t index = user_controlled_x+user_controlled_y;
if(index > array_size)
   throw std::range_error("");

With SafeInt, you get something like this:
SafeInt<size_t> index =
SafeInt<uint32_t>(user_controlled_x)+SafeInt<uint32_t>(user_controlled_y);
if(index > array_size)
   throw std::range_error("");

SafeInt doesn't do everything for you, but it gets the difficult checks out
of the way, and lets the programmer handle the easy, program specific
checks.  A more fully range checked class might be appropriate, but there
isn't as much field experience with that.


>
>>   In these situations, you probably want to throw an exception, or
>> terminate the program.
>
>
> This s off-topic but IMO you never ever want to terminate a program when
> you use a language that supports exceptions, like C++
>

If you hit undefined behavior, you should probably terminate the program as
quickly as possible.  This is the approach that "stack canary"
implementations take.  However, since we are talking about C++ spec work
here, we should probably only talk about things with defined behavior.  For
those, I agree with you that exceptions are the better approach.


> Saturation, assertions in debug mode, and ignoring aren't very good
>> options from a security standpoint.
>>
> Maybe. It depends on how you define security.
> But for sure those are good options in several application domains, and a
> standard C++ library facility should consider them all (as much as
> possible)
>

Let's take it from a code review standpoint.  If SafeInt (or some
alternative) is used, then any place where C++ "a+b" is not the same as
arithmetic "a+b", you should get an exception, or there should be something
explicit in the code indicating that a different policy is required at that
point.  Maybe the "drop-in" stuff only allows exceptions, but saturation
and modulo arithmetic get free functions?  "short myVal =
saturation_cast<short>(x, 0, 100);"

--




--20cf3011dc13766a9704cf7b3a53
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Nov 27, 2012 at 7:32 AM, Fernand=
o Cacciola <span dir=3D"ltr">&lt;<a href=3D"mailto:fernando.cacciola@gmail.=
com" target=3D"_blank">fernando.cacciola@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div class=3D"im"=
>On Mon, Nov 26, 2012 at 1:59 PM, Ben Craig <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ben.craig@gmail.com" target=3D"_blank">ben.craig@gmail.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

Some large use cases for SafeInt are computing sizes for buffers and array =
indices.</blockquote></div><div><br>Hmmm.<br>Can you elaborate how is SafeI=
nt safe when it comes to an array index in the case of an array of runtime =
size? Which I believe is, by far, the most common type of array (buffer, co=
ntainer, etc)<br>


<br>For *that* purpose I think the proper tool is an integer with runtime b=
oundaries (a number of these have been implemented and proposed to, for ins=
tance, Boost)<br></div></div></div></blockquote><div><br>Without a facility=
 like SafeInt, a developer would likely write (buggy) code like this:<br>
size_t index =3D user_controlled_x+user_controlled_y;<br>if(index &gt; arra=
y_size)<br>=A0=A0 throw std::range_error(&quot;&quot;);<br><br>With SafeInt=
, you get something like this:<br>SafeInt&lt;size_t&gt; index =3D SafeInt&l=
t;uint32_t&gt;(user_controlled_x)+SafeInt&lt;uint32_t&gt;(user_controlled_y=
);<br>
if(index &gt; array_size)<br>=A0=A0 throw std::range_error(&quot;&quot;);<b=
r><br>SafeInt doesn&#39;t do everything for you, but it gets the difficult =
checks out of the way, and lets the programmer handle the easy, program spe=
cific checks.=A0 A more fully range checked class might be appropriate, but=
 there isn&#39;t as much field experience with that.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><div>=A0</div><div class=3D"im"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">


=A0 In these situations, you probably want to throw an exception, or termin=
ate the program.=A0</blockquote></div><div><br>This s off-topic but IMO you=
 never ever want to terminate a program when you use a language that suppor=
ts exceptions, like C++<br>
</div></div></div></blockquote><div><br>If you hit undefined behavior, you =
should probably terminate the program as quickly as possible.=A0 This is th=
e approach that &quot;stack canary&quot; implementations take.=A0 However, =
since we are talking about C++ spec work here, we should probably only talk=
 about things with defined behavior.=A0 For those, I agree with you that ex=
ceptions are the better approach.<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 Saturation, assertions in debug mode, and ignoring aren&#39;t very good op=
tions from a security standpoint.<br></blockquote></div><div>Maybe. It depe=
nds on how you define security.<br>But for sure those are good options in s=
everal application domains, and a standard C++ library facility should cons=
ider them all (as much as possible) <br>
</div></div></div></blockquote><div>=A0</div><div>Let&#39;s take it from a =
code review standpoint.=A0 If SafeInt (or some alternative) is used, then a=
ny place where C++ &quot;a+b&quot; is not the same as arithmetic &quot;a+b&=
quot;, you should get an exception, or there should be something explicit i=
n the code indicating that a different policy is required at that point.=A0=
 Maybe the &quot;drop-in&quot; stuff only allows exceptions, but saturation=
 and modulo arithmetic get free functions?=A0 &quot;short myVal =3D saturat=
ion_cast&lt;short&gt;(x, 0, 100);&quot;<br>
</div></div><br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--20cf3011dc13766a9704cf7b3a53--

.

------=_Part_565_29449654.1354037099224
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, November 27, 2012 3:54:38 PM UTC+1, Ben Craig wrote:

> Without a facility like SafeInt, a developer would likely write (buggy)
> code like this:
> size_t index = user_controlled_x+user_controlled_y;
> if(index > array_size)
>    throw std::range_error("");
>
> With SafeInt, you get something like this:
> SafeInt<size_t> index =
> SafeInt<uint32_t>(user_controlled_x)+SafeInt<uint32_t>(user_controlled_y);
> if(index > array_size)
>    throw std::range_error("");
>
> I assume you meant index >= array_size? :p

--




------=_Part_565_29449654.1354037099224
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, November 27, 2012 3:54:38 PM UTC+1, Ben Craig wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">Without a facility like SafeInt, a de=
veloper would likely write (buggy) code like this:<br><div class=3D"gmail_q=
uote"><div>
size_t index =3D user_controlled_x+user_<wbr>controlled_y;<br>if(index &gt;=
 array_size)<br>&nbsp;&nbsp; throw std::range_error("");<br><br>With SafeIn=
t, you get something like this:<br>SafeInt&lt;size_t&gt; index =3D SafeInt&=
lt;uint32_t&gt;(user_<wbr>controlled_x)+SafeInt&lt;uint32_<wbr>t&gt;(user_c=
ontrolled_y);<br>
if(index &gt; array_size)<br>&nbsp;&nbsp; throw std::range_error("");<br><b=
r></div></div></blockquote><div>I assume you meant index &gt;=3D array_size=
? :p&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_565_29449654.1354037099224--

.

--e89a8f923f3a31627404cf7d66e8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 26, 2012 at 11:16 PM, <robertmacleranramey@gmail.com> wrote:

>
>
> On Monday, November 26, 2012 3:32:09 PM UTC-8, viboes wrote:
>>
>>  Le 23/11/12 18:10, robertmac...@gmail.com a =E9crit :safe and integers
>> could be orthogonal, but I don't see how a safe<T> class could provide
>> safety to rational as overflow is avoided by using gcd while doing the
>> addition of two rationals and many other tricks.
>>
>
> then safe<rational> wouldn't throw on overflow - because it can't happen.
>

Strictly speaking, you can end up with an irreductible fraction. In that
case, operating with such a fraction can overflow.

OTOH, gcd is time consuming, so it is sometimes more efficient to just use
big enough integers as long as you can, for which you need to have a form
of overflow management.



--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=20




--e89a8f923f3a31627404cf7d66e8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, Nov 26, 2012 =
at 11:16 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:robertmacleranramey@g=
mail.com" target=3D"_blank">robertmacleranramey@gmail.com</a>&gt;</span> wr=
ote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>On Monday, November 26, 2012 3:32:09=
 PM UTC-8, viboes wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">


 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 23/11/12 18:10,
      <a>robertmac...@gmail.com</a> a =E9crit=A0:safe and integers could be=
 orthogonal, but I don&#39;t see how a
    safe&lt;T&gt; class could provide safety to rational as overflow is
    avoided by using gcd while doing the addition of two rationals and
    many other tricks.<br></div></div></blockquote><div><br>then safe&lt;ra=
tional&gt; wouldn&#39;t throw on overflow - because it can&#39;t happen.=A0=
</div></blockquote><div><br>Strictly speaking, you can end up with an irred=
uctible fraction. In that case, operating with such a fraction can overflow=
..<br>

<br>OTOH, gcd is time consuming, so it is sometimes more efficient to just =
use big enough integers as long as you can, for which you need to have a fo=
rm of overflow management.<br><br></div><br></div><br>-- <br>Fernando Cacci=
ola<br>

SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com=
">http://www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f923f3a31627404cf7d66e8--

.

------=_Part_1173_15786425.1354037589070
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, November 27, 2012 2:33:03 PM UTC+1, Fernando Cacciola wrote:

> This s off-topic but IMO you never ever want to terminate a program when
> you use a language that supports exceptions, like C++
>
> Why not? The difference between aborting and throwing is basically whether
you can catch and continue (safely).
For the majority of apps aborting is fine for certain errors and exceptions
aren't without cost and can't be used everywhere.

--




------=_Part_1173_15786425.1354037589070
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, November 27, 2012 2:33:03 PM UTC+1, Fernando Cacciola wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div>This s off-topic but IMO=
 you never ever want to terminate a program when you use a language that su=
pports exceptions, like C++<br><div class=3D"gmail_quote"><div><br></div></=
div></div></blockquote><div>Why not?&nbsp;The difference between aborting a=
nd throwing is basically whether you can catch and continue (safely).&nbsp;=
</div><div>For the majority of apps aborting is fine for certain errors and=
 exceptions aren't without cost and can't be used everywhere.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1173_15786425.1354037589070--

.

--047d7b621df89144b504cf7d81b2
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 27, 2012 at 11:54 AM, Ben Craig <ben.craig@gmail.com> wrote:

>
>
> On Tue, Nov 27, 2012 at 7:32 AM, Fernando Cacciola <
> fernando.cacciola@gmail.com> wrote:
>
>>
>> On Mon, Nov 26, 2012 at 1:59 PM, Ben Craig <ben.craig@gmail.com> wrote:
>>
>>> Some large use cases for SafeInt are computing sizes for buffers and
>>> array indices.
>>
>>
>> Hmmm.
>> Can you elaborate how is SafeInt safe when it comes to an array index in
>> the case of an array of runtime size? Which I believe is, by far, the most
>> common type of array (buffer, container, etc)
>>
>> For *that* purpose I think the proper tool is an integer with runtime
>> boundaries (a number of these have been implemented and proposed to, for
>> instance, Boost)
>>
>
> Without a facility like SafeInt, a developer would likely write (buggy)
> code like this:
> size_t index = user_controlled_x+user_controlled_y;
> if(index > array_size)
>    throw std::range_error("");
>
> With SafeInt, you get something like this:
> SafeInt<size_t> index =
> SafeInt<uint32_t>(user_controlled_x)+SafeInt<uint32_t>(user_controlled_y);
> if(index > array_size)
>    throw std::range_error("");
>
> SafeInt doesn't do everything for you, but it gets the difficult checks
> out of the way, and lets the programmer handle the easy, program specific
> checks.  A more fully range checked class might be appropriate, but there
> isn't as much field experience with that.
>

OK, I see the motivation to make sure you don't compute an index value the
wrong way, accidentally because of the current limitations with integer
types.


>
>
>>
>>>   In these situations, you probably want to throw an exception, or
>>> terminate the program.
>>
>>
>> This s off-topic but IMO you never ever want to terminate a program when
>> you use a language that supports exceptions, like C++
>>
>
> If you hit undefined behavior, you should probably terminate the program
> as quickly as possible.  This is the approach that "stack canary"
> implementations take.  However, since we are talking about C++ spec work
> here, we should probably only talk about things with defined behavior.  For
> those, I agree with you that exceptions are the better approach.
>
>
>> Saturation, assertions in debug mode, and ignoring aren't very good
>>> options from a security standpoint.
>>>
>> Maybe. It depends on how you define security.
>> But for sure those are good options in several application domains, and a
>> standard C++ library facility should consider them all (as much as
>> possible)
>>
>
> Let's take it from a code review standpoint.  If SafeInt (or some
> alternative) is used, then any place where C++ "a+b" is not the same as
> arithmetic "a+b", you should get an exception, or there should be something
> explicit in the code indicating that a different policy is required at that
> point.  Maybe the "drop-in" stuff only allows exceptions, but saturation
> and modulo arithmetic get free functions?  "short myVal =
> saturation_cast<short>(x, 0, 100);"
>
> I agree that, for an utility intended to be a drop-in replacement for
'int', should simply throw in the case of overflow (when it is assigned, or
in corner cases).
I also agree that such an utility might be useful.

Having said that, I still think we need a lower layer, used by such an
utility, that would also be used by other similar utilities (like
fixed_int<>). That lower layer would provide general building blocks, with
your saturation_cast<short> being a possible one.



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b621df89144b504cf7d81b2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Tue, Nov 27, 2012 =
at 11:54 AM, Ben Craig <span dir=3D"ltr">&lt;<a href=3D"mailto:ben.craig@gm=
ail.com" target=3D"_blank">ben.craig@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">

<br><br><div class=3D"gmail_quote"><div class=3D"im">On Tue, Nov 27, 2012 a=
t 7:32 AM, Fernando Cacciola <span dir=3D"ltr">&lt;<a href=3D"mailto:fernan=
do.cacciola@gmail.com" target=3D"_blank">fernando.cacciola@gmail.com</a>&gt=
;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div>On Mon, Nov =
26, 2012 at 1:59 PM, Ben Craig <span dir=3D"ltr">&lt;<a href=3D"mailto:ben.=
craig@gmail.com" target=3D"_blank">ben.craig@gmail.com</a>&gt;</span> wrote=
:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

Some large use cases for SafeInt are computing sizes for buffers and array =
indices.</blockquote></div><div><br>Hmmm.<br>Can you elaborate how is SafeI=
nt safe when it comes to an array index in the case of an array of runtime =
size? Which I believe is, by far, the most common type of array (buffer, co=
ntainer, etc)<br>




<br>For *that* purpose I think the proper tool is an integer with runtime b=
oundaries (a number of these have been implemented and proposed to, for ins=
tance, Boost)<br></div></div></div></blockquote></div><div><br>Without a fa=
cility like SafeInt, a developer would likely write (buggy) code like this:=
<br>


size_t index =3D user_controlled_x+user_controlled_y;<br>if(index &gt; arra=
y_size)<br>=A0=A0 throw std::range_error(&quot;&quot;);<br><br>With SafeInt=
, you get something like this:<br>SafeInt&lt;size_t&gt; index =3D SafeInt&l=
t;uint32_t&gt;(user_controlled_x)+SafeInt&lt;uint32_t&gt;(user_controlled_y=
);<br>


if(index &gt; array_size)<br>=A0=A0 throw std::range_error(&quot;&quot;);<b=
r><br>SafeInt doesn&#39;t do everything for you, but it gets the difficult =
checks out of the way, and lets the programmer handle the easy, program spe=
cific checks.=A0 A more fully range checked class might be appropriate, but=
 there isn&#39;t as much field experience with that.<br>

</div></div></blockquote><div><br>OK, I see the motivation to make sure you=
 don&#39;t compute an index value the wrong way, accidentally because of th=
e current limitations with integer types.<br>=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div class=3D"gmail_quote"><div>
<br></div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div>=A0</div><div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">




=A0 In these situations, you probably want to throw an exception, or termin=
ate the program.=A0</blockquote></div><div><br>This s off-topic but IMO you=
 never ever want to terminate a program when you use a language that suppor=
ts exceptions, like C++<br>


</div></div></div></blockquote></div><div><br>If you hit undefined behavior=
, you should probably terminate the program as quickly as possible.=A0 This=
 is the approach that &quot;stack canary&quot; implementations take.=A0 How=
ever, since we are talking about C++ spec work here, we should probably onl=
y talk about things with defined behavior.=A0 For those, I agree with you t=
hat exceptions are the better approach.<br>


=A0</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


 Saturation, assertions in debug mode, and ignoring aren&#39;t very good op=
tions from a security standpoint.<br></blockquote></div><div>Maybe. It depe=
nds on how you define security.<br>But for sure those are good options in s=
everal application domains, and a standard C++ library facility should cons=
ider them all (as much as possible) <br>


</div></div></div></blockquote><div>=A0</div></div><div>Let&#39;s take it f=
rom a code review standpoint.=A0 If SafeInt (or some alternative) is used, =
then any place where C++ &quot;a+b&quot; is not the same as arithmetic &quo=
t;a+b&quot;, you should get an exception, or there should be something expl=
icit in the code indicating that a different policy is required at that poi=
nt.=A0 Maybe the &quot;drop-in&quot; stuff only allows exceptions, but satu=
ration and modulo arithmetic get free functions?=A0 &quot;short myVal =3D s=
aturation_cast&lt;short&gt;(x, 0, 100);&quot;<span class=3D"HOEnZb"><font c=
olor=3D"#888888"><br>


</font></span></div></div><span class=3D"HOEnZb"><font color=3D"#888888"><b=
r></font></span></blockquote><div>I agree that, for an utility intended to =
be a drop-in replacement for &#39;int&#39;, should simply throw in the case=
 of overflow (when it is assigned, or in corner cases).<br>

I also agree that such an utility might be useful.<br><br>Having said that,=
 I still think we need a lower layer, used by such an utility, that would a=
lso be used by other similar utilities (like fixed_int&lt;&gt;). That lower=
 layer would provide general building blocks, with your saturation_cast&lt;=
short&gt; being a possible one.<br>

<br></div></div><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSoft C=
onsulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">http://=
www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b621df89144b504cf7d81b2--

.

--047d7b621ede58bf4a04cf7d963e
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 27, 2012 at 2:33 PM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Tuesday, November 27, 2012 2:33:03 PM UTC+1, Fernando Cacciola wrote:
>
>> This s off-topic but IMO you never ever want to terminate a program when
>> you use a language that supports exceptions, like C++
>>
>> Why not? The difference between aborting and throwing is basically
> whether you can catch and continue (safely).
> For the majority of apps aborting is fine for certain errors and
> exceptions aren't without cost and can't be used everywhere.
>

I'm tempted to respond, but I think this thread is not the correct place.
(and I'm not sure where would be)

Anyway, let me just rephrase that: IMO, the *end user* never ever wants you
the programmer to structure the program in such a way that the *entire
application* must abort as opposed to the current "task" (task from the end
user POV )


>



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b621ede58bf4a04cf7d963e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Tue, Nov 27, 2012 =
at 2:33 PM, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=3D"mailto:olafv=
dspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On Tuesday, November 27, 2012 2:33:03 PM UTC+1, Fernando =
Cacciola wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>This s off-=
topic but IMO you never ever want to terminate a program when you use a lan=
guage that supports exceptions, like C++<br>

<div class=3D"gmail_quote"><div><br></div></div></div></blockquote></div><d=
iv>Why not?=A0The difference between aborting and throwing is basically whe=
ther you can catch and continue (safely).=A0</div><div>For the majority of =
apps aborting is fine for certain errors and exceptions aren&#39;t without =
cost and can&#39;t be used everywhere.</div>

</blockquote><div><br>I&#39;m tempted to respond, but I think this thread i=
s not the correct place. (and I&#39;m not sure where would be)<br><br>Anywa=
y, let me just rephrase that: IMO, the *end user* never ever wants you the =
programmer to structure the program in such a way that the *entire applicat=
ion* must abort as opposed to the current &quot;task&quot; (task from the e=
nd user POV )<br>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span class=3D"HOEnZb"><font color=
=3D"#888888">
=A0<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Fernando =
Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-co=
nsulting.com">http://www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b621ede58bf4a04cf7d963e--

.

Le 27/11/12 00:28, Lawrence Crowl a =E9crit :
> On 11/26/12, robertmacleranramey@gmail.com
> <robertmacleranramey@gmail.com> wrote:
>> I wanted to avoid this so as to keep the "drop-in" replacement
>> functionality. I want people take a program with bugs in it,
>> change all their "int" to safe<int>, etc. run the program and trap
>> errors. This makes the library much, much more attractive to use.
> I agree that this approach will produce a valuable tool.
>
>
I don't know if I understand your use case, you want to use safe as a=20
debug tool, then IMHO the best should be to terminate the program, isn't=20
it?

I don't know if your SafeInt/safe<T> prevents from assignments from=20
signed values to unsigned types, but this could also be useful.

-- Vicente

--=20




.

This is a multi-part message in MIME format.
--------------000703000901070902070103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 27/11/12 03:16, robertmacleranramey@gmail.com a =E9crit :
>
>
> On Monday, November 26, 2012 3:32:09 PM UTC-8, viboes wrote:
>
>     Le 23/11/12 18:10, robertmac...@gmail.com <javascript:> a
>     =E9crit :safe and integers could be orthogonal, but I don't see how
>     a safe<T> class could provide safety to rational as overflow is
>     avoided by using gcd while doing the addition of two rationals and
>     many other tricks.
>
>
> then safe<rational> wouldn't throw on overflow - because it can't happen.
Sorry, I wanted to say "to avoid intermediary overflows (before=20
normalization)". To compute  {n1/d1}+{n2/d2} the rational library makes=20
some intermediate operation on the rational value type as products,=20
additions and divisions that can overflow. But nothing ensures you that=20
the template parameter T of rational is safe.
> Same with save<multi-precision>.  But currently safe<T> throws on at=20
> attempt to divide by zero.  So the concept is easily extended to other=20
> numeric types.  I can easily imagine a safe<float> and safe<double>=20
> which could overflow, underflow and device by zero.  Basically safe<T>=20
> would throw anytime and operation on T doesn't yield the expected=20
> mathematical result.
>
Maybe you are right. We need a concrete proposal (only for integral=20
types or for numbers in general) to continue the discussion.

--Vicente

--=20




--------------000703000901070902070103
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 27/11/12 03:16,
      <a class="moz-txt-link-abbreviated" href="mailto:robertmacleranramey@gmail.com">robertmacleranramey@gmail.com</a> a &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite="mid:71a089ef-f658-4277-b1c1-8e7b4216a2be@isocpp.org"
      type="cite"><br>
      <br>
      On Monday, November 26, 2012 3:32:09 PM UTC-8, viboes wrote:
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <div bgcolor="#FFFFFF" text="#000000">
          <div>Le 23/11/12 18:10, <a moz-do-not-send="true"
              href="javascript:" target="_blank"
              gdf-obfuscated-mailto="rPLY3l9TfcYJ">robertmac...@gmail.com</a>
            a &eacute;crit&nbsp;:safe and integers could be orthogonal, but I don't
            see how a safe&lt;T&gt; class could provide safety to
            rational as overflow is avoided by using gcd while doing the
            addition of two rationals and many other tricks.<br>
          </div>
        </div>
      </blockquote>
      <div><br>
        then safe&lt;rational&gt; wouldn't throw on overflow - because
        it can't happen.&nbsp; </div>
    </blockquote>
    Sorry, I wanted to say "to avoid intermediary overflows (before
    normalization)". To compute&nbsp; {n1/d1}+{n2/d2} the rational library
    makes some intermediate operation on the rational value type as
    products, additions and divisions that can overflow. But nothing
    ensures you that the template parameter T of rational is safe. <br>
    <blockquote
      cite="mid:71a089ef-f658-4277-b1c1-8e7b4216a2be@isocpp.org"
      type="cite">
      <div>Same with save&lt;multi-precision&gt;.&nbsp; But currently
        safe&lt;T&gt; throws on at attempt to divide by zero.&nbsp; So the
        concept is easily extended to other numeric types.&nbsp; I can easily
        imagine a safe&lt;float&gt; and safe&lt;double&gt; which could
        overflow, underflow and device by zero.&nbsp; Basically safe&lt;T&gt;
        would throw anytime and operation on T doesn't yield the
        expected mathematical result.<br>
        <br>
      </div>
    </blockquote>
    Maybe you are right. We need a concrete proposal (only for integral
    types or for numbers in general) to continue the discussion.<br>
    <br>
    --Vicente<br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--------------000703000901070902070103--

.

--Apple-Mail=_EB7DD61A-6ED8-4B25-B239-D44C805CDF94
Content-Type: text/plain; charset=ISO-8859-1

On Nov 27, 2012, at 9:33 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> On Tuesday, November 27, 2012 2:33:03 PM UTC+1, Fernando Cacciola wrote:
> This s off-topic but IMO you never ever want to terminate a program when you use a language that supports exceptions, like C++
>
> Why not? The difference between aborting and throwing is basically whether you can catch and continue (safely).
> For the majority of apps aborting is fine for certain errors and exceptions aren't without cost and can't be used everywhere.

The key is "for the majority of apps" is the key.

This is a decision that needs to be made by the app developer, not the library developer.

-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists@gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

--




--Apple-Mail=_EB7DD61A-6ED8-4B25-B239-D44C805CDF94
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space; "><div><div>On Nov 27, 20=
12, at 9:33 AM, Olaf van der Spek &lt;<a href=3D"mailto:olafvdspek@gmail.co=
m">olafvdspek@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-=
newline"><blockquote type=3D"cite">On Tuesday, November 27, 2012 2:33:03 PM=
 UTC+1, Fernando Cacciola wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: r=
gb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: s=
tatic; z-index: auto; ">This s off-topic but IMO you never ever want to ter=
minate a program when you use a language that supports exceptions, like C++=
<br><div class=3D"gmail_quote"><br></div></blockquote><div>Why not?&nbsp;Th=
e difference between aborting and throwing is basically whether you can cat=
ch and continue (safely).&nbsp;</div><div>For the majority of apps aborting=
 is fine for certain errors and exceptions aren't without cost and can't be=
 used everywhere.</div></blockquote><div><br></div>The key is "for the majo=
rity of apps" is the key.</div><div><br></div><div>This is a decision that =
needs to be made by the app developer, not the library developer.</div><div=
><br></div><div apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; color:=
 rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-=
spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decoration=
s-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-widt=
h: 0px; font-size: medium; ">-- Marshall<br><br>Marshall Clow &nbsp; &nbsp;=
 Idio Software &nbsp; &lt;<a href=3D"mailto:mclow.lists@gmail.com">mailto:m=
clow.lists@gmail.com</a>&gt;<br><br>A.D. 1517: Martin Luther nails his 95 T=
heses to the church door and is promptly moderated down to (-1, Flamebait).=
<br>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;-- Yu Suzuki</span>

</div>
<br></body></html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--Apple-Mail=_EB7DD61A-6ED8-4B25-B239-D44C805CDF94--

.

--Apple-Mail=_5BA88FD2-6E7F-4B38-9901-091E60C8480A
Content-Type: text/plain; charset=ISO-8859-1

On Nov 27, 2012, at 11:44 AM, Marshall Clow <mclow.lists@gmail.com> wrote:

> On Nov 27, 2012, at 9:33 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>
>> On Tuesday, November 27, 2012 2:33:03 PM UTC+1, Fernando Cacciola wrote:
>> This s off-topic but IMO you never ever want to terminate a program when you use a language that supports exceptions, like C++
>>
>> Why not? The difference between aborting and throwing is basically whether you can catch and continue (safely).
>> For the majority of apps aborting is fine for certain errors and exceptions aren't without cost and can't be used everywhere.
>
> The key is "for the majority of apps" is the key.

Sigh. Bad editing strikes again.
 "For the majority of apps" is the key phrase.

> This is a decision that needs to be made by the app developer, not the library developer.



-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists@gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

--




--Apple-Mail=_5BA88FD2-6E7F-4B38-9901-091E60C8480A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space; "><div><div>On Nov 27, 20=
12, at 11:44 AM, Marshall Clow &lt;<a href=3D"mailto:mclow.lists@gmail.com"=
>mclow.lists@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-n=
ewline"><blockquote type=3D"cite"><meta http-equiv=3D"Content-Type" content=
=3D"text/html charset=3Diso-8859-1"><div style=3D"word-wrap: break-word; -w=
ebkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>=
On Nov 27, 2012, at 9:33 AM, Olaf van der Spek &lt;<a href=3D"mailto:olafvd=
spek@gmail.com">olafvdspek@gmail.com</a>&gt; wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite">On Tuesday, November 27, 20=
12 2:33:03 PM UTC+1, Fernando Cacciola wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-=
left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex=
; position: static; z-index: auto; ">This s off-topic but IMO you never eve=
r want to terminate a program when you use a language that supports excepti=
ons, like C++<br><div class=3D"gmail_quote"><br></div></blockquote><div>Why=
 not?&nbsp;The difference between aborting and throwing is basically whethe=
r you can catch and continue (safely).&nbsp;</div><div>For the majority of =
apps aborting is fine for certain errors and exceptions aren't without cost=
 and can't be used everywhere.</div></blockquote><div><br></div>The key is =
"for the majority of apps" is the key.</div></div></blockquote><div><br></d=
iv>Sigh. Bad editing strikes again.</div><div><span class=3D"Apple-tab-span=
" style=3D"white-space:pre"> </span>"For the majority of apps" is the key p=
hrase.</div><div><br><blockquote type=3D"cite"><div style=3D"word-wrap: bre=
ak-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "=
><div>This is a decision that needs to be made by the app developer, not th=
e library developer.</div></div></blockquote></div><div><br></div><br><div =
apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; border=
-spacing: 0px; ">-- Marshall<br><br>Marshall Clow &nbsp; &nbsp; Idio Softwa=
re &nbsp; &lt;<a href=3D"mailto:mclow.lists@gmail.com">mailto:mclow.lists@g=
mail.com</a>&gt;<br><br>A.D. 1517: Martin Luther nails his 95 Theses to the=
 church door and is promptly moderated down to (-1, Flamebait).<br>&nbsp;&n=
bsp; &nbsp; &nbsp; &nbsp;-- Yu Suzuki</span>

</div>
<br></body></html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--Apple-Mail=_5BA88FD2-6E7F-4B38-9901-091E60C8480A--

.

--047d7b621df8fb48b004cf7fa67b
Content-Type: text/plain; charset=ISO-8859-1

Olaf moved this into std-discussions.


This is a decision that needs to be made by the app developer, not the
> library developer.
>
>
And that totally summarizes my point, but since it seems that is not at all
obvious what that implies in terms of library design, I will try to
elaborate on that in the other thread.


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b621df8fb48b004cf7fa67b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Olaf moved this into std-discussions.<br><div class=3D"gmail_extra"><br><br=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"wo=
rd-wrap:break-word">

<div>This is a decision that needs to be made by the app developer, not the=
 library developer.</div><div><br></div></div></blockquote><div><br>And tha=
t totally summarizes my point, but since it seems that is not at all obviou=
s what that implies in terms of library design, I will try to elaborate on =
that in the other thread.</div>

</div><br clear=3D"all"><div><br></div>-- <br>Fernando Cacciola<br>SciSoft =
Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">http:/=
/www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b621df8fb48b004cf7fa67b--

.

------=_Part_1243_32468864.1354048370897
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, November 27, 2012 5:44:44 AM UTC-8, Fernando Cacciola wrote:
>
>
> On Mon, Nov 26, 2012 at 2:45 PM, <robertmac...@gmail.com <javascript:>>wrote:
>
>>
>>
>> On Sunday, November 25, 2012 11:17:04 PM UTC-8, viboes wrote:
>>>
>>>
>>>
>>>>  c) I considered a policy parameter of some sort to indicate how to
>>> handle overflows - they use an enum to select.  But I rejected the idea for
>>> two reasons
>>>
>>> i) more complexity with very little value.
>>> ii)  I couldn't see how to do it with something like
>>>
>>> safe<int32> x;
>>> safe<int16> y;
>>> safe<int32> z;
>>> z = x + y;  // where would the policy parameter go?
>>>
>>> With the Lawrence proposal you don't have overflow as far as you don't
>>> loss range. So the natural place is to use it only with assignment.
>>>
>>
>> It's exactly the same with safe<T>.  EXCEPT the case where safe<int64> +
>> safe<int64> where there is not large type to hold the intermediate result.
>> That is, the overflow can occur before the assignment.  In this case, it
>> throws immediately.  I struggled on how to avoid this - but solutions
>> seemed more and more heavy weight.
>>
>> Hmm, how isn't is as simple as using a software-based int128 number type?
>

a software based int128 type doesn't handle the problem.  what about

int64 x, y;
y = x * x * x;

Only an arbitray length multi-precision intermediate type could defer all
checking until the next assigment.

>
>
> Imagine you have a program and you get a division by zero exception . What
> do you do
> You change the program so that, instead of attempting a computation that
> cannot be performed, it determines the case and handle the "exceptional
> case" manually in a different way.
> You could just let the exception abort the current execution block but
> that's NOT the way division by zero is handled.
>

Now suppose you change all the 'int' for safe<int> and you discover a point
where overflow is occurring?  What do you do?

you fix the program.


> By analogy to the div-by-zero case, and IME (and I do have experience
> writing algorithms that need handle overflow, both integer and
> floating-point), you also want to detect the case before-hand so you can do
> something else.
>

of course


> Simply changing a program so that instead of UB it throws is a step ahead,
> but it's a too general solution that surely works for general application
> code.
>

this is the intent of SafeInt and safe<int>.


> But if you are writing a numerical algorithm OTOH you need, for example,
> to have a clean and simple way to handle the overflow and do something else
> *without* aborting the computation.
>

That's a whole other problem.  The solution is application dependent.  One
way would be to use arbitrary multi-precision numbers - but that's a
different library.


>
>
>>
>>
>>> But do the PO proposal or your Safe library allow to saturate on
>>> overflow, assert, ignore, ...?
>>>
>>
>> The safe<T> throws an exception.  Users would have to trap the exception
>> if they want to handle it in some specific way.  I considered alternatives,
>> but I felt that if something traps it's almost always an unrecoverable
>> error - ie a programming error
>>
>
> Wait.
>


> Numerical overflow is *rarely* a programming error. It's the consequence
> of finite precision when crunching numbers.
>

that depends on the application.  usually if i just use int or unsigned int
I'm expecting the result to match the expected mathmetical result.  If
overflow or divide by zero occurs it's a bug. If one wanted to use
safe<int> for cases where an overflow is expected, one could trap the
exception like

safe<int> x, y;

try{
    x = 256 * 256 * 256 * 256 * 256;
 }
catch(boost:numeric_exception e){
  .... // do your own thing.
}

generally, I'm not crazy about this code - but it has its uses.

Robert Ramey

--




------=_Part_1243_32468864.1354048370897
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, November 27, 2012 5:44:44 AM UTC-8, Fernando Cacciola w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br><div class=3D"gm=
ail_quote">On Mon, Nov 26, 2012 at 2:45 PM,  <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"CD8M03wU7cQJ">r=
obertmac...@gmail.com</a><wbr>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br><br>On Sunday, November 25, 2012 11=
:17:04 PM UTC-8, viboes wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

<div bgcolor=3D"#FFFFFF" text=3D"#000000"><br>
 =20
   =20
 =20
  <blockquote type=3D"cite"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br></b=
lockquote></blockquote><blockquote type=3D"cite">
      <div>
        c) I considered a policy parameter of some sort to indicate how
        to handle overflows - they use an enum to select.&nbsp; But I
        rejected the idea for two reasons<br>
        <br>
        i) more complexity with very little value.<br>
        ii)&nbsp; I couldn't see how to do it with something like<br>
        <br>
        safe&lt;int32&gt; x;<br>
        safe&lt;int16&gt; y;<br>
        safe&lt;int32&gt; z;<br>
        z =3D x + y;&nbsp; // where would the policy parameter go?<br>
      </div>
    </blockquote>
    With the
   =20
    Lawrence proposal you don't have overflow as far as you don't loss
    range. So the natural place is to use it only with assignment.<br></div=
></blockquote></div><div><br>It's exactly the same with safe&lt;T&gt;.&nbsp=
; EXCEPT the case where safe&lt;int64&gt; + safe&lt;int64&gt; where there i=
s not large type to hold the intermediate result. That is, the overflow can=
 occur before the assignment.&nbsp; In this case, it throws immediately.&nb=
sp; I struggled on how to avoid this - but solutions seemed more and more h=
eavy weight.<br>

<br></div></blockquote><div>Hmm, how isn't is as simple as using a software=
-based int128 number type?<br></div></div></div></blockquote><div><br>a sof=
tware based int128 type doesn't handle the problem.&nbsp; what about <br><b=
r>int64 x, y;<br>y =3D x * x * x;<br><br>Only an arbitray length multi-prec=
ision intermediate type could defer all checking until the next assigment. =
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div class=3D"g=
mail_quote"><div>&nbsp;<br></div><div><br>Imagine you have a program and yo=
u get a division by zero exception . What do you do<br>You change the progr=
am so that, instead of attempting a computation that cannot be performed, i=
t determines the case and handle the "exceptional case" manually in a diffe=
rent way.<br>

You could just let the exception abort the current execution block but that=
's NOT the way division by zero is handled.<br></div></div></div></blockquo=
te><div>&nbsp;<br>Now suppose you change all the 'int' for safe&lt;int&gt; =
and you discover a point where overflow is occurring?&nbsp; What do you do?=
<br></div><div><br>you fix the program.<br>&nbsp;<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div><div class=3D"gmail_quote"><div>

By analogy to the div-by-zero case, and IME (and I do have experience writi=
ng algorithms that need handle overflow, both integer and floating-point), =
you also want to detect the case before-hand so you can do something else.<=
br></div></div></div></blockquote><div><br>of course<br>&nbsp;<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div><div class=3D"gmail_quote"><=
div>

Simply changing a program so that instead of UB it throws is a step ahead, =
but it's a too general solution that surely works for general application c=
ode. </div></div></div></blockquote><div><br>this is the intent of SafeInt =
and safe&lt;int&gt;.<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div><div class=3D"gmail_quote"><div>But if you are writing a num=
erical algorithm OTOH you need, for example, to have a clean and simple way=
 to handle the overflow and do something else *without* aborting the comput=
ation.<br></div></div></div></blockquote><div><br>That's a whole other prob=
lem.&nbsp; The solution is application dependent.&nbsp; One way would be to=
 use arbitrary multi-precision numbers - but that's a different library. <b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div class=3D=
"gmail_quote"><div>

<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div></div><div><div>&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">

<div bgcolor=3D"#FFFFFF" text=3D"#000000">But do the PO proposal or your
    Safe library allow to saturate on overflow, assert, ignore, ...?<br></d=
iv></blockquote></div><div><br>The safe&lt;T&gt; throws an exception.&nbsp;=
 Users would have to trap the exception if they want to handle it in some s=
pecific way.&nbsp; I considered alternatives, but I felt that if something =
traps it's almost always an unrecoverable error - ie a programming error </=
div>

</blockquote><div><br>Wait.<br></div></div></div></blockquote><div>&nbsp;</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div class=3D"gmail_q=
uote"><div>Numerical overflow is *rarely* a programming error. It's the con=
sequence of finite precision when crunching numbers.<br></div></div></div><=
/blockquote><div><br>that depends on the application.&nbsp; usually if i ju=
st use int or unsigned int I'm expecting the result to match the expected m=
athmetical result.&nbsp; If overflow or divide by zero occurs it's a bug. I=
f one wanted to use safe&lt;int&gt; for cases where an overflow is expected=
, one could trap the exception like<br><br>safe&lt;int&gt; x, y;<br><br>try=
{<br>&nbsp;&nbsp;&nbsp; x =3D 256 * 256 * 256 * 256 * 256;<br>&nbsp;}<br>ca=
tch(boost:numeric_exception e){<br>&nbsp; .... // do your own thing.<br>}<b=
r><br>generally, I'm not crazy about this code - but it has its uses.<br><b=
r>Robert Ramey<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1243_32468864.1354048370897--

.

------=_Part_331_24029055.1354048655958
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, November 27, 2012 6:54:38 AM UTC-8, Ben Craig wrote:
>
>
>
> On Tue, Nov 27, 2012 at 7:32 AM, Fernando Cacciola <fernando...@gmail.com<javascript:>
> > wrote:
>
>>
>> On Mon, Nov 26, 2012 at 1:59 PM, Ben Craig <ben....@gmail.com<javascript:>
>> > wrote:
>>
>>> Some large use cases for SafeInt are computing sizes for buffers and
>>> array indices.
>>
>>
>
> Let's take it from a code review standpoint.  If SafeInt (or some
> alternative) is used, then any place where C++ "a+b" is not the same as
> arithmetic "a+b", you should get an exception,
>

+1

It's really about producing demonstrably correct code. That is - code which
does what one would expect it to do. That's the whole intent - nothing more
nothing less.

Robert Ramey

--




------=_Part_331_24029055.1354048655958
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, November 27, 2012 6:54:38 AM UTC-8, Ben Craig wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><br><br><div class=3D"gmail_quote=
">On Tue, Nov 27, 2012 at 7:32 AM, Fernando Cacciola <span dir=3D"ltr">&lt;=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Ormv6MwY=
H9AJ">fernando...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div><br><div class=3D"gmail_quote"><div>On Mon, Nov 26, 2012 at 1:59 PM, B=
en Craig <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"Ormv6MwYH9AJ">ben....@gmail.com</a>&gt;</span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

Some large use cases for SafeInt are computing sizes for buffers and array =
indices.</blockquote></div></div></div></blockquote><br><div>&nbsp;</div><d=
iv>Let's take it from a code review standpoint.&nbsp; If SafeInt (or some a=
lternative) is used, then any place where C++ "a+b" is not the same as arit=
hmetic "a+b", you should get an exception, </div></div></blockquote><div><b=
r>+1<br><br>It's really about producing demonstrably correct code. That is =
- code which does what one would expect it to do. That's the whole intent -=
 nothing more nothing less.<br><br>Robert Ramey<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_331_24029055.1354048655958--

.

------=_Part_154_29968258.1354048989497
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Tuesday, November 27, 2012 10:05:27 AM UTC-8, viboes wrote:
>
> Le 27/11/12 00:28, Lawrence Crowl a =EF=BF=BDcrit :=20
> > On 11/26/12, robertmac...@gmail.com <javascript:>=20
>
>
> I don't know if your SafeInt/safe<T> prevents from assignments from=20
> signed values to unsigned types, but this could also be useful.=20
>

I can't speak for SafeInt but safe<T> will throw if a negative value is=20
assigned to an unsigned int. =20

>
> -- Vicente=20
>

--=20




------=_Part_154_29968258.1354048989497
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, November 27, 2012 10:05:27 AM UTC-8, viboes wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">Le 27/11/12 00:28, Lawrence Crowl a=
 =EF=BF=BDcrit :
<br>&gt; On 11/26/12, <a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"hUzlNVuTEI0J">robertmac...@gmail.com</a>
<br><br>
<br>I don't know if your SafeInt/safe&lt;T&gt; prevents from assignments fr=
om=20
<br>signed values to unsigned types, but this could also be useful.
<br></blockquote><div><br>I can't speak for SafeInt but safe&lt;T&gt; will =
throw if a negative value is assigned to an unsigned int.&nbsp; <br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">
<br>-- Vicente
<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_154_29968258.1354048989497--

.

------=_Part_23_24017783.1354063907908
Content-Type: text/plain; charset=ISO-8859-1

Floating point is in some ways more complex. An issue that would be hard to
deal with would be the classic large number + small number, where the
result ends up either not changing, or losing a lot of the significant bits
of the small number. This could range from by design to disaster,
completely depending on the application.

I've thought about it, but believe it would take a different class.

Having it be a class does make it apply all over the place - here's how -
for almost all operations, the return type is a SafeInt or reference to
SafeInt. It is thus 'sticky'. For example, say you had:

int x, y, z;
unsigned int ret;
// assign x, y, z

ret = SafeInt<int>(x) * y + z;

The multiplication is performed, checked, result is a temporary SafeInt of
type int, addition is performed and checked, result is another temporary.
Finally, assignment is performed and checked.

It is true that it would be hard to get 3rd party code to use it, though
this depends on how the maintainers feel, whether you'd like to fork it.
Really the same sort of issue as replacing strcpy with strcpy_s, or any
other update.


Alternately, you could change the declaration of one or more of x, y, z to
SafeInt<int>, and then everywhere x is used in the subsequent code is then
checked.

The idea about the operations is interesting, but I would bet that it would
cause the following to blow up and not compile:

std::string s = "Hello";
s += " World";

On Thursday, November 22, 2012 5:45:42 AM UTC-8, Fernando Cacciola wrote:

> I would most definitely like to have a standardized interface to handle
> numerical overflow.
>
> I do however have some reservations on doing it by means of an integer
> wrapper.
>
> First, I think we need such "safe numeric operations" to handle floating
> point values just as well. While the mechanisms are different, the
> requirements are exactly the same (and floating-point does overflow no
> matter how big their range is). In fact, I think we need it for arbitrary
> numeric types, including rationals, complex, user-defined extended
> precision, interval, etc... (and consistently defined for even unlimited
> precision numeric types, even if the overflow test always yields false)
>
> Second, I wonder if a wrapper is the best interface. Since this is a
> "security" utility, it needs to be consistently applied *all over* the
> relevant source code, otherwise it is not really effective
> A lot, if not most, critical and complex numeric code (where this is
> mostly needed) depends on third-party libraries, and in the numerical
> community there is a huge base of reusable code that is (yet) not
> sufficiently generic to let you get away with simple using a wrapper type
> at the highest level.
> In other words, you might use SafeInt in your own code but it is not easy
> to have third-party code use it as well.
>
> Since the overflow is always a side effect of operations, and operations
> are expressed in C++ via operators (and functions), I wonder if the library
> shouldn't be in a form of "safe operators and functions" as opposed to
> "safe numeric type".
>
> IIUC, the current operator overloading mechanism should allow something
> like the following:
>
> #include <safe_numeric_operations>
>
> // This "activates" the overflow detection on any supported type,
> including builtin types
> using std::safe_numeric_operations ;
>
> void test()
> {
>   try
>   {
>      int a = std::numeric_limits<int>::max();
>
>      // std::safe_numeric_operations::operator + (int,int) being called
> here
>      int r = a + a ;
>   }
>   catch ( std::bad_numeric_conversion ) { }
> }
>
>
>
>
> On Wed, Nov 21, 2012 at 11:25 PM, <robertmac...@gmail.com <javascript:>>wrote:
>
>>
>>
>> On Wednesday, November 7, 2012 6:59:50 PM UTC-8, Ben Craig wrote:
>>>
>>> SafeInt information can be found here <http://safeint.codeplex.com/>.
>>> ...
>>>
>>
>> I also found myself interested in this code.  When I got around to
>> looking at it I felt it could be improved.  Being a "booster" I wanted to
>> leverage on Boost stuff to make a simpler implementation.  The result of my
>> efforts can be found at
>> http://rrsd.com/blincubator.com/bi_library/safe-numerics/
>>
>> Main differences are:
>> a) follows Boost/C++ library conventions as to naming, formating etc.
>> b) Is many many lines shorter due to the usage of more meta-programming
>> technique in the implementation.
>> c) Includes an exhaustive set of tests including all combinations of
>> corner cases - generated with boost pre-processor library.
>> d) defines concepts for "numeric" types and includes concept checking via
>> the boost concept checking library.
>> e) includes documentation more in line with currently recommended
>> "formal" style.
>>
>> Robert Ramey
>>
>>  --
>>
>>
>>
>>
>
>
>
> --
> Fernando Cacciola
> SciSoft Consulting, Founder
> http://www.scisoft-consulting.com
>

--




------=_Part_23_24017783.1354063907908
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Floating point is in some ways more complex. An issue that would be ha=
rd to deal with would be the classic large number + small number, where the=
 result ends up either not changing, or losing a lot of the significant bit=
s of the small number. This could range from by design to disaster, complet=
ely depending on the application.</div><div>&nbsp;</div><div>I've thought a=
bout it, but believe it would take a different class.</div><div>&nbsp;</div=
><div>Having it be a class does make it apply all over the place - here's h=
ow - for almost all operations, the return type is a SafeInt or reference t=
o SafeInt. It is thus 'sticky'. For example, say you had:</div><div>&nbsp;<=
/div><div>int x, y, z;</div><div>unsigned int ret;</div><div>// assign x, y=
, z</div><div>&nbsp;</div><div>ret =3D SafeInt&lt;int&gt;(x) * y + z;</div>=
<div>&nbsp;</div><div>The multiplication is performed, checked, result is a=
 temporary SafeInt of type int, addition is performed and checked, result i=
s another temporary. Finally, assignment is performed and checked.</div><di=
v>&nbsp;</div><div>It is true that it would be hard to get 3rd party code t=
o use it, though this depends on how the maintainers feel, whether you'd li=
ke to fork it. Really the same sort of issue as replacing strcpy with strcp=
y_s, or any other update.</div><div>&nbsp;</div><div>&nbsp;</div><div>Alter=
nately, you could change the declaration of one or more of x, y, z to SafeI=
nt&lt;int&gt;, and then everywhere x is used in the subsequent code is then=
 checked.</div><div>&nbsp;</div><div>The idea about the operations is inter=
esting, but I would bet that it would cause the following to blow up and no=
t compile:</div><div>&nbsp;</div><div>std::string s =3D "Hello";</div><div>=
s +=3D " World";</div><div><br>On Thursday, November 22, 2012 5:45:42 AM UT=
C-8, Fernando Cacciola wrote:</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;">I would mo=
st definitely like to have a standardized interface to handle numerical ove=
rflow.<br><br>I do however have some reservations on doing it by means of a=
n integer wrapper.<br><br>First, I think we need such "safe numeric operati=
ons" to handle floating point values just as well. While the mechanisms are=
 different, the requirements are exactly the same (and floating-point does =
overflow no matter how big their range is). In fact, I think we need it for=
 arbitrary numeric types, including rationals, complex, user-defined extend=
ed precision, interval, etc... (and consistently defined for even unlimited=
 precision numeric types, even if the overflow test always yields false)<br=
>

<br>Second, I wonder if a wrapper is the best interface. Since this is a "s=
ecurity" utility, it needs to be consistently applied *all over* the releva=
nt source code, otherwise it is not really effective<br>A lot, if not most,=
 critical and complex numeric code (where this is mostly needed) depends on=
 third-party libraries, and in the numerical community there is a huge base=
 of reusable code that is (yet) not sufficiently generic to let you get awa=
y with simple using a wrapper type at the highest level. <br>

In other words, you might use SafeInt in your own code but it is not easy t=
o have third-party code use it as well.<br><br>Since the overflow is always=
 a side effect of operations, and operations are expressed in C++ via opera=
tors (and functions), I wonder if the library shouldn't be in a form of "sa=
fe operators and functions" as opposed to "safe numeric type".<br>

<br>IIUC, the current operator overloading mechanism should allow something=
 like the following:<br><br>#include &lt;safe_numeric_operations&gt;<br><br=
>// This "activates" the overflow detection on any supported type, includin=
g builtin types<br>

using std::safe_numeric_operations ;<br><br>void test()<br>{<br>&nbsp; try<=
br>&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp; int a =3D std::numeric_limits&lt;in=
t&gt;::max(<wbr>);<br><br>&nbsp;&nbsp;&nbsp;&nbsp; // std::safe_numeric_ope=
rations::<wbr>operator + (int,int) being called here<br>&nbsp;&nbsp;&nbsp;&=
nbsp; int r =3D a + a ;<br>

&nbsp; }<br>&nbsp; catch ( std::bad_numeric_conversion ) { }<br>}<br><br><b=
r><div><br><br><div class=3D"gmail_quote">On Wed, Nov 21, 2012 at 11:25 PM,=
  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"LXTDalCMlzUJ">robertmac...@gmail.com</a><wbr>&gt;</span> wr=
ote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><br><br>On Wednesday, November 7, 2012 6:59:50=
 PM UTC-8, Ben Craig wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;">

SafeInt information can be found <a href=3D"http://safeint.codeplex.com/" t=
arget=3D"_blank">here</a>.&nbsp; ...<br></blockquote><div><br>I also found =
myself interested in this code.&nbsp; When I got around to looking at it I =
felt it could be improved.&nbsp; Being a "booster" I wanted to leverage on =
Boost stuff to make a simpler implementation.&nbsp; The result of my effort=
s can be found at <a href=3D"http://rrsd.com/blincubator.com/bi_library/saf=
e-numerics/" target=3D"_blank">http://rrsd.com/blincubator.<wbr>com/bi_libr=
ary/safe-numerics/</a><br>

<br>Main differences are:<br>a) follows Boost/C++ library conventions as to=
 naming, formating etc.<br>b) Is many many lines shorter due to the usage o=
f more meta-programming technique in the implementation.<br>c) Includes an =
exhaustive set of tests including all combinations of corner cases - genera=
ted with boost pre-processor library.<br>

d) defines concepts for "numeric" types and includes concept checking via t=
he boost concept checking library.<br>e) includes documentation more in lin=
e with currently recommended "formal" style.<br><br>

Robert Ramey<span><font color=3D"#888888"><br><br></font></span></div><span=
><font color=3D"#888888">

<p></p>

-- <br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Fernando =
Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-co=
nsulting.com" target=3D"_blank">http://www.scisoft-consulting.<wbr>com</a><=
br>
</div>
</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_23_24017783.1354063907908--

.

------=_Part_560_7618471.1354064557591
Content-Type: text/plain; charset=ISO-8859-1

If you are going to derive something from my work, please follow the
license. It doesn't ask much, just that you keep attribution and the
license. If you are going to completely rewrite something based on my work,
then you may not need a license (I Am Not A Lawyer, one should be asked),
but attribution would be nice.

Other than that, I don't have time to review an entirely new library. I do
believe portions of Boost and/or the standard library could be leveraged to
reduce some of the code in SafeInt. I'd assume that if we made it part of
the standard that would be a work item.

On Wednesday, November 21, 2012 6:25:33 PM UTC-8, robertmac...@gmail.com
wrote:

>
>
> On Wednesday, November 7, 2012 6:59:50 PM UTC-8, Ben Craig wrote:
>>
>> SafeInt information can be found here <http://safeint.codeplex.com/>.
>> ...
>>
>
> I also found myself interested in this code.  When I got around to looking
> at it I felt it could be improved.  Being a "booster" I wanted to leverage
> on Boost stuff to make a simpler implementation.  The result of my efforts
> can be found at http://rrsd.com/blincubator.com/bi_library/safe-numerics/
>
> Main differences are:
> a) follows Boost/C++ library conventions as to naming, formating etc.
> b) Is many many lines shorter due to the usage of more meta-programming
> technique in the implementation.
> c) Includes an exhaustive set of tests including all combinations of
> corner cases - generated with boost pre-processor library.
> d) defines concepts for "numeric" types and includes concept checking via
> the boost concept checking library.
> e) includes documentation more in line with currently recommended "formal"
> style.
>
> Robert Ramey
>
>

--




------=_Part_560_7618471.1354064557591
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>If you are going to derive something from my work, please follow the l=
icense. It doesn't ask much, just that you keep attribution and the license=
.. If you are going to completely rewrite something based on my work, then y=
ou may not need a license (I Am Not A Lawyer, one should be asked), but att=
ribution would be nice.</div><div>&nbsp;</div><div>Other than that, I don't=
 have time to review an entirely new library. I do believe portions of Boos=
t and/or the standard library could be leveraged to reduce some of the code=
 in SafeInt. I'd assume that if we made it part of the standard that would =
be a work item.</div><div><br>On Wednesday, November 21, 2012 6:25:33 PM UT=
C-8, robertmac...@gmail.com wrote:</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><br><b=
r>On Wednesday, November 7, 2012 6:59:50 PM UTC-8, Ben Craig wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left:=
 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border=
-left-style: solid;">SafeInt information can be found <a href=3D"http://saf=
eint.codeplex.com/" target=3D"_blank">here</a>.&nbsp; ...<br></blockquote><=
div><br>I also found myself interested in this code.&nbsp; When I got aroun=
d to looking at it I felt it could be improved.&nbsp; Being a "booster" I w=
anted to leverage on Boost stuff to make a simpler implementation.&nbsp; Th=
e result of my efforts can be found at <a href=3D"http://rrsd.com/blincubat=
or.com/bi_library/safe-numerics/" target=3D"_blank">http://rrsd.com/blincub=
ator.<wbr>com/bi_library/safe-numerics/</a><br><br>Main differences are:<br=
>a) follows Boost/C++ library conventions as to naming, formating etc.<br>b=
) Is many many lines shorter due to the usage of more meta-programming tech=
nique in the implementation.<br>c) Includes an exhaustive set of tests incl=
uding all combinations of corner cases - generated with boost pre-processor=
 library.<br>d) defines concepts for "numeric" types and includes concept c=
hecking via the boost concept checking library.<br>e) includes documentatio=
n more in line with currently recommended "formal" style.<br><br>Robert Ram=
ey<br><br></div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_560_7618471.1354064557591--

.

------=_Part_4_27894460.1354064863351
Content-Type: text/plain; charset=ISO-8859-1

Yes - += 2 on this comment -

The overhead of this class is quite small, often to the point of being no
more overhead than what would happen if you put the correct checks into the
code. But it does have overhead, and we don't need it injected into:

for (unsigned int j = 0; j < 10; ++j)


> Don't forget the essential C++ maxim: pay only for what you use.
>>
>> There is a lot of code that's just fine with non-secure integers. They no
>> need to have overflow checks and such every time time they loop from 0 to
>> 240. They aren't going to overflow their loop counter. There are many such
>> occurrences in a code-base where the structure and nature of the code means
>> that overflow is just not a realistic possibility.
>>
>> This means that whatever we adopt has to be an opt-in mechanism, not an
>> opt-out.
>>
>

--




------=_Part_4_27894460.1354064863351
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Yes - +=3D 2 on this comment - </div><div>&nbsp;</div><div>The overhea=
d of this class is quite small, often to the point of being no more overhea=
d than what would happen if you put the correct checks into the code. But i=
t does have overhead, and we don't need it injected into:</div><div>&nbsp;<=
/div><div>for (unsigned int j =3D 0; j &lt; 10; ++j)</div><div>&nbsp;</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204,=
 204); border-left-width: 1px; border-left-style: solid;"><div>Don't forget=
 the essential C++ maxim: pay only for what you use.<br><br>There is a lot =
of code that's just fine with non-secure integers. They no need to have ove=
rflow checks and such every time time they loop from 0 to 240. They aren't =
going to overflow their loop counter. There are many such occurrences in a =
code-base where the structure and nature of the code means that overflow is=
 just not a realistic possibility.<br><br>This means that whatever we adopt=
 has to be an opt-in mechanism, not an opt-out.</div>
</blockquote></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4_27894460.1354064863351--

.

------=_Part_588_16464102.1354065907128
Content-Type: text/plain; charset=ISO-8859-1

The problem is actually a bit worse than one would assume from a quick
look. There's a number of wrinkles to the standard, and a couple of
difficult corner cases - here's some examples:

unsigned int x;
signed char y;

Now consider the result of (x & y) - if the high bit is set, then it will
sign extend. You may then end up with some of the upper 24 bits of x set,
which the programmer may have not expected. Another issue is to consider a
shift of more bits than are available - if I'm not mistaken, this is
implementation dependent, possibly undefined. There is more than one way to
perform modulus of two mixed sign numbers. The class deals with some of
this by use of asserts.

As an aside, some of the thinking about this parallels what we went through
while working on this. At one time, we had an implementation that would
have an internal bool to see if it was valid or not, you'd just let it go,
then check later to see if it was valid or not - much the same for testing
a float to see if it was not a number. Turned out to be unusable, since a
simple check like if (SafeCheckedInt<int>(x) < 0) might throw.

A problem with many of these suggestions that SafeInt does deal with is the
following:

int foo(unsigned short s);

SafeInt<int> x = init();

foo(x);

The casting operator overloading will ensure that x is within range of a
short, or throw. This is an extremely common mistake, and this is the only
approach I'm aware of that solves it.

BTW, thanks to all of you for the extremely interesting ideas and questions
- I will likely have several more replies before I am caught up...

On Thursday, November 22, 2012 9:02:42 AM UTC-8, Fernando Cacciola wrote:

> OK, I agree with your observations about silently overloading operators.
>
> OTOH, I still think there is something to be considered in the fact that
> it is the operations that overflow (and other unwanted side effects), not
> the numbers themselves, so I would propose a layer of overloaded functions,
> that can be applied on any type, including built-in types, and on top of
> that a higher-level wrapper (or wrappers like in Robert's library)
>
> The advantage of doing so, following your own observations, is that in
> most numeric code, you don't really need to check for all operations, so a
> performance critical algorithm might not be able to just use the wrapper as
> a drop-in replacement for int, yet it could be made secure by adding
> checked operations where specifically necessary.
>
> Having said all that, I would like to at least mention the fact that there
> is a largest picture to consider here, where integer overflow is just one
> case. I'm referring to the domain of numerical robustness in general, and
> while a comprehensive work on that is way out of the scope of a relatively
> simple proposal like this one, the big picture should still be constantly
> present and considered.
>
> From the more general point of view of numerical robustness, throwing an
> exception when a numerical computation could not be performed (such as in
> the case of integer overflow) is the most basic building block, but it is
> still too low-level. There is a lot of work in the research community about
> how to truly handle numerical limitations, as opposed to not handling in
> order (which is what a safe-int does). Unfortunately, most of that work is
> specific to an application domain and a given numeric type or types, so
> it's hard to extrapolate general idioms and utilities. However, there are
> two basic elements that are usually found in most of them:
>
> First there is the general mechanism of using a proper type to perform an
> operation. For intance, an int64 to operate two int32. This is the
> mechanism used by SafeInt and Robert's code, but it's actually used in a
> lot of places dealing with integer numerics. So, we should standardized
> that, such that it is generally available to any programmer to do something
> like:
>
> auto r = (secure)a + b;
>
> here (secure) would bootstrap an operator+ which selects the proper return
> type to guarantee the addition does not overflow (or you could just have
> secure_add(a,b) or whatever)
>
> Second, there is the general requirement to test whether the result of
> operations are reliable, beyond just overflow.
> One idiom that has emerged in recent years and which I found intuitive
> enough to be general is the concept of "certified arithmetic" (usually
> implemented with interval floating-point numbers). The idea is that, on the
> one hand, the result of operations carry a certificate (explicit or not) to
> indicate if it succeeded or not, and on the other hand, triboolean logic is
> used along, made general and easy.  In terms of safe_int this would mean
> that instead of throwing, the result is just flaged as overflow, much like
> a floating-point saturates to +- INF, but, when you try to compare, the
> answer is "maybe" (and if you want to convert it to plain int it throws)
>
> The general form of the idiom would be something like this:
>
> auto e = ( a  + b == c + d ) ;
> if ( certainy(e) )
> {
> }
> else if ( certainly_not(e ) )
> {
> }
> else
> {
>   // can't tell. It not possible to compare the numbers
> }
>
> Here, if a,b,c,d are integers numbers, and either of the additions
> overflow, the code flows to the last else, and without even any exception
> being thrown.
> The trick is that operator == returns a tribool (or it's generalization
> uncertain<bool>)
>
>
> Best
>
>
> On Thu, Nov 22, 2012 at 1:58 PM, Nicol Bolas <jmck...@gmail.com<javascript:>
> > wrote:
>
>>
>>
>> On Thursday, November 22, 2012 5:45:42 AM UTC-8, Fernando Cacciola wrote:
>>>
>>> I would most definitely like to have a standardized interface to handle
>>> numerical overflow.
>>>
>>> I do however have some reservations on doing it by means of an integer
>>> wrapper.
>>>
>>> First, I think we need such "safe numeric operations" to handle floating
>>> point values just as well. While the mechanisms are different, the
>>> requirements are exactly the same (and floating-point does overflow no
>>> matter how big their range is). In fact, I think we need it for arbitrary
>>> numeric types, including rationals, complex, user-defined extended
>>> precision, interval, etc... (and consistently defined for even unlimited
>>> precision numeric types, even if the overflow test always yields false)
>>>
>>> Second, I wonder if a wrapper is the best interface. Since this is a
>>> "security" utility, it needs to be consistently applied *all over* the
>>> relevant source code, otherwise it is not really effective
>>>
>>
>> Don't forget the essential C++ maxim: pay only for what you use.
>>
>> There is a lot of code that's just fine with non-secure integers. They no
>> need to have overflow checks and such every time time they loop from 0 to
>> 240. They aren't going to overflow their loop counter. There are many such
>> occurrences in a code-base where the structure and nature of the code means
>> that overflow is just not a realistic possibility.
>>
>> This means that whatever we adopt has to be an opt-in mechanism, not an
>> opt-out.
>>
>>
>>> A lot, if not most, critical and complex numeric code (where this is
>>> mostly needed) depends on third-party libraries, and in the numerical
>>> community there is a huge base of reusable code that is (yet) not
>>> sufficiently generic to let you get away with simple using a wrapper type
>>> at the highest level.
>>> In other words, you might use SafeInt in your own code but it is not
>>> easy to have third-party code use it as well.
>>>
>>> Since the overflow is always a side effect of operations, and operations
>>> are expressed in C++ via operators (and functions), I wonder if the library
>>> shouldn't be in a form of "safe operators and functions" as opposed to
>>> "safe numeric type".
>>
>>
>>> IIUC, the current operator overloading mechanism should allow something
>>> like the following:
>>>
>>> #include <safe_numeric_operations>
>>>
>>> // This "activates" the overflow detection on any supported type,
>>> including builtin types
>>> using std::safe_numeric_operations ;
>>>
>>> void test()
>>> {
>>>   try
>>>   {
>>>      int a = std::numeric_limits<int>::max(**);
>>>
>>>      // std::safe_numeric_operations::**operator + (int,int) being
>>> called here
>>>      int r = a + a ;
>>>   }
>>>   catch ( std::bad_numeric_conversion ) { }
>>> }
>>>
>>
>> Ignoring the fact that a recompile would suddenly cause massive amounts
>> of code to potentially throw std::bad_numeric_conversion without the
>> knowledge of that code's owners (ie: we can't do that), there's also the
>> practical issue that this won't magically affect any *C* code that
>> people often use.
>>
>> But even more importantly, I'm pretty sure you can't overload
>> operator+(int, int). Besides being practically infeasible by creating the
>> possibility of exceptions in potentially exception-unsafe code, it's simply
>> not possible.
>>
>>
>>>
>>>
>>>
>>>
>>> On Wed, Nov 21, 2012 at 11:25 PM, <robertmac...@gmail.com**> wrote:
>>>
>>>>
>>>>
>>>> On Wednesday, November 7, 2012 6:59:50 PM UTC-8, Ben Craig wrote:
>>>>>
>>>>> SafeInt information can be found here <http://safeint.codeplex.com/>.
>>>>> ...
>>>>>
>>>>
>>>> I also found myself interested in this code.  When I got around to
>>>> looking at it I felt it could be improved.  Being a "booster" I wanted to
>>>> leverage on Boost stuff to make a simpler implementation.  The result of my
>>>> efforts can be found at http://rrsd.com/blincubator.**
>>>> com/bi_library/safe-numerics/<http://rrsd.com/blincubator.com/bi_library/safe-numerics/>
>>>>
>>>> Main differences are:
>>>> a) follows Boost/C++ library conventions as to naming, formating etc.
>>>> b) Is many many lines shorter due to the usage of more meta-programming
>>>> technique in the implementation.
>>>> c) Includes an exhaustive set of tests including all combinations of
>>>> corner cases - generated with boost pre-processor library.
>>>> d) defines concepts for "numeric" types and includes concept checking
>>>> via the boost concept checking library.
>>>> e) includes documentation more in line with currently recommended
>>>> "formal" style.
>>>>
>>>> Robert Ramey
>>>>
>>>>  --
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Fernando Cacciola
>>> SciSoft Consulting, Founder
>>> http://www.scisoft-consulting.**com <http://www.scisoft-consulting.com>
>>>
>>  --
>>
>>
>>
>>
>
>
>
> --
> Fernando Cacciola
> SciSoft Consulting, Founder
> http://www.scisoft-consulting.com
>

--




------=_Part_588_16464102.1354065907128
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>The problem is actually a bit worse than one would assume from a quick=
 look. There's a number of wrinkles to the standard, and a couple of diffic=
ult corner cases - here's some examples:</div><div>&nbsp;</div><div>unsigne=
d int x;</div><div>signed char y;</div><div>&nbsp;</div><div>Now consider t=
he result of (x &amp; y) - if the high bit is set, then it will sign extend=
.. You may then end up with some of the upper 24 bits of x set, which the pr=
ogrammer may have not expected. Another issue is to consider a shift of mor=
e bits than&nbsp;are available - if I'm not mistaken, this is implementatio=
n dependent, possibly undefined. There is more than one way to perform modu=
lus of two mixed sign numbers. The class deals with some of this by use of =
asserts.</div><div>&nbsp;</div><div>As an aside, some of the thinking about=
 this parallels what we went through while working on this. At one time, we=
 had an implementation that would have an internal bool to see if it was va=
lid or not, you'd just let it go, then check later to see if it was valid o=
r not - much the same for testing a float to see if it was not a number. Tu=
rned out to be unusable, since a simple check like if (SafeCheckedInt&lt;in=
t&gt;(x) &lt; 0) might throw.<br><br>A problem with many of these suggestio=
ns that SafeInt does deal with is the following:</div><div>&nbsp;</div><div=
>int foo(unsigned short s);</div><div>&nbsp;</div><div>SafeInt&lt;int&gt; x=
 =3D init();</div><div>&nbsp;</div><div>foo(x);</div><div>&nbsp;</div><div>=
The casting operator overloading will ensure that x is within range of a sh=
ort, or throw. This is an extremely common mistake, and this is the only ap=
proach I'm aware of that solves it.</div><div>&nbsp;</div><div>BTW, thanks =
to all of you for the extremely interesting ideas and questions - I will li=
kely have several more replies before I am caught up...</div><div><br>On Th=
ursday, November 22, 2012 9:02:42 AM UTC-8, Fernando Cacciola wrote:</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddin=
g-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px;=
 border-left-style: solid;">OK, I agree with your observations about silent=
ly overloading operators.<br><br>OTOH, I still think there is something to =
be considered in the fact that it is the operations that overflow (and othe=
r unwanted side effects), not the numbers themselves, so I would propose a =
layer of overloaded functions, that can be applied on any type, including b=
uilt-in types, and on top of that a higher-level wrapper (or wrappers like =
in Robert's library)<br>

<br>The advantage of doing so, following your own observations, is that in =
most numeric code, you don't really need to check for all operations, so a =
performance critical algorithm might not be able to just use the wrapper as=
 a drop-in replacement for int, yet it could be made secure by adding check=
ed operations where specifically necessary.<br>

<br>Having said all that, I would like to at least mention the fact that th=
ere is a largest picture to consider here, where integer overflow is just o=
ne case. I'm referring to the domain of numerical robustness in general, an=
d while a comprehensive work on that is way out of the scope of a relativel=
y simple proposal like this one, the big picture should still be constantly=
 present and considered.<br>

<br>From the more general point of view of numerical robustness, throwing a=
n exception when a numerical computation could not be performed (such as in=
 the case of integer overflow) is the most basic building block, but it is =
still too low-level. There is a lot of work in the research community about=
 how to truly handle numerical limitations, as opposed to not handling in o=
rder (which is what a safe-int does). Unfortunately, most of that work is s=
pecific to an application domain and a given numeric type or types, so it's=
 hard to extrapolate general idioms and utilities. However, there are two b=
asic elements that are usually found in most of them:<br>

<br>First there is the general mechanism of using a proper type to perform =
an operation. For intance, an int64 to operate two int32. This is the mecha=
nism used by SafeInt and Robert's code, but it's actually used in a lot of =
places dealing with integer numerics. So, we should standardized that, such=
 that it is generally available to any programmer to do something like:<br>

<br>auto r =3D (secure)a + b;<br><br>here (secure) would bootstrap an opera=
tor+ which selects the proper return type to guarantee the addition does no=
t overflow (or you could just have secure_add(a,b) or whatever)<br><br>Seco=
nd, there is the general requirement to test whether the result of operatio=
ns are reliable, beyond just overflow. <br>

One idiom that has emerged in recent years and which I found intuitive enou=
gh to be general is the concept of "certified arithmetic" (usually implemen=
ted with interval floating-point numbers). The idea is that, on the one han=
d, the result of operations carry a certificate (explicit or not) to indica=
te if it succeeded or not, and on the other hand, triboolean logic is used =
along, made general and easy.&nbsp; In terms of safe_int this would mean th=
at instead of throwing, the result is just flaged as overflow, much like a =
floating-point saturates to +- INF, but, when you try to compare, the answe=
r is "maybe" (and if you want to convert it to plain int it throws)<br>

<br>The general form of the idiom would be something like this:<br><br>auto=
 e =3D ( a&nbsp; + b =3D=3D c + d ) ;<br>if ( certainy(e) )<br>{<br>}<br>el=
se if ( certainly_not(e ) )<br>{<br>}<br>else<br>{<br>&nbsp; // can't tell.=
 It not possible to compare the numbers<br>

}<br><br>Here, if a,b,c,d are integers numbers, and either of the additions=
 overflow, the code flows to the last else, and without even any exception =
being thrown.<br>The trick is that operator =3D=3D returns a tribool (or it=
's generalization uncertain&lt;bool&gt;)<br>

<br><br>Best<br><div><br><br><div class=3D"gmail_quote">On Thu, Nov 22, 201=
2 at 1:58 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"Cjlx43qCWWoJ">jmck...@gmail.com</a>=
&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div><br><br>On Thursday, November 22, 2012 5:=
45:42 AM UTC-8, Fernando Cacciola wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;">

I would most definitely like to have a standardized interface to handle num=
erical overflow.<br><br>I do however have some reservations on doing it by =
means of an integer wrapper.<br><br>First, I think we need such "safe numer=
ic operations" to handle floating point values just as well. While the mech=
anisms are different, the requirements are exactly the same (and floating-p=
oint does overflow no matter how big their range is). In fact, I think we n=
eed it for arbitrary numeric types, including rationals, complex, user-defi=
ned extended precision, interval, etc... (and consistently defined for even=
 unlimited precision numeric types, even if the overflow test always yields=
 false)<br>



<br>Second, I wonder if a wrapper is the best interface. Since this is a "s=
ecurity" utility, it needs to be consistently applied *all over* the releva=
nt source code, otherwise it is not really effective<br></blockquote>

</div><div><br>Don't forget the essential C++ maxim: pay only for what you =
use.<br><br>There is a lot of code that's just fine with non-secure integer=
s. They no need to have overflow checks and such every time time they loop =
from 0 to 240. They aren't going to overflow their loop counter. There are =
many such occurrences in a code-base where the structure and nature of the =
code means that overflow is just not a realistic possibility.<br>

<br>This means that whatever we adopt has to be an opt-in mechanism, not an=
 opt-out.<br>&nbsp;</div><div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204=
, 204); border-left-width: 1px; border-left-style: solid;">

A lot, if not most, critical and complex numeric code (where this is mostly=
 needed) depends on third-party libraries, and in the numerical community t=
here is a huge base of reusable code that is (yet) not sufficiently generic=
 to let you get away with simple using a wrapper type at the highest level.=
 <br>



In other words, you might use SafeInt in your own code but it is not easy t=
o have third-party code use it as well.<br><br>Since the overflow is always=
 a side effect of operations, and operations are expressed in C++ via opera=
tors (and functions), I wonder if the library shouldn't be in a form of "sa=
fe operators and functions" as opposed to "safe numeric type".&nbsp;</block=
quote>

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;">

<br>IIUC, the current operator overloading mechanism should allow something=
 like the following:<br><br>#include &lt;safe_numeric_operations&gt;<br><br=
>// This "activates" the overflow detection on any supported type, includin=
g builtin types<br>



using std::safe_numeric_operations ;<br><br>void test()<br>{<br>&nbsp; try<=
br>&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp; int a =3D std::numeric_limits&lt;in=
t&gt;::max(<u></u><wbr>);<br><br>&nbsp;&nbsp;&nbsp;&nbsp; // std::safe_nume=
ric_operations::<u></u><wbr>operator + (int,int) being called here<br>

&nbsp;&nbsp;&nbsp;&nbsp; int r =3D a + a ;<br>

&nbsp; }<br>&nbsp; catch ( std::bad_numeric_conversion ) { }<br>}<br></bloc=
kquote></div><div><br>Ignoring the fact that a recompile would suddenly cau=
se massive amounts of code to potentially throw std::bad_numeric_conversion=
 without the knowledge of that code's owners (ie: we can't do that), there'=
s also the practical issue that this won't magically affect any <i>C</i> co=
de that people often use.<br>

<br>But even more importantly, I'm pretty sure you can't overload operator+=
(int, int). Besides being practically infeasible by creating the possibilit=
y of exceptions in potentially exception-unsafe code, it's simply not possi=
ble.<br>

&nbsp;</div><div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><br><br><div><br><br><div cla=
ss=3D"gmail_quote">On Wed, Nov 21, 2012 at 11:25 PM,  <span dir=3D"ltr">&lt=
;<a>robertmac...@gmail.com</a><u></u>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><br><br>On Wednesday, November 7, 2012 6:59:50=
 PM UTC-8, Ben Craig wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;">



SafeInt information can be found <a href=3D"http://safeint.codeplex.com/" t=
arget=3D"_blank">here</a>.&nbsp; ...<br></blockquote><div><br>I also found =
myself interested in this code.&nbsp; When I got around to looking at it I =
felt it could be improved.&nbsp; Being a "booster" I wanted to leverage on =
Boost stuff to make a simpler implementation.&nbsp; The result of my effort=
s can be found at <a href=3D"http://rrsd.com/blincubator.com/bi_library/saf=
e-numerics/" target=3D"_blank">http://rrsd.com/blincubator.<u></u>co<wbr>m/=
bi_library/safe-numerics/</a><br>



<br>Main differences are:<br>a) follows Boost/C++ library conventions as to=
 naming, formating etc.<br>b) Is many many lines shorter due to the usage o=
f more meta-programming technique in the implementation.<br>c) Includes an =
exhaustive set of tests including all combinations of corner cases - genera=
ted with boost pre-processor library.<br>



d) defines concepts for "numeric" types and includes concept checking via t=
he boost concept checking library.<br>e) includes documentation more in lin=
e with currently recommended "formal" style.<br><br>



Robert Ramey<span><font color=3D"#888888"><br><br></font></span></div><span=
><font color=3D"#888888">

<p></p>

-- <br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Fernando =
Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-co=
nsulting.com" target=3D"_blank">http://www.scisoft-consulting.<u></u><wbr>c=
om</a><br>


</div>
</blockquote>

<p></p></div>

-- <br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>Sc=
iSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com" =
target=3D"_blank">http://www.scisoft-consulting.<wbr>com</a><br>
</div>
</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_588_16464102.1354065907128--

.

------=_Part_61_25975378.1354066629621
Content-Type: text/plain; charset=ISO-8859-1


On Thursday, November 22, 2012 1:33:38 PM UTC-8, Fernando Cacciola wrote:
>
> On Thu, Nov 22, 2012 at 5:57 PM, <robertmac...@gmail.com <javascript:>>wrote:
>
>> For instance, both SafeInt's and your code *requires* a primitive
>> operation that returns the result in a larger type such that it is known
>> not to overflow.
>>
> No, not true - for type A, B, operator op:

SafeInt<A> op B returns a SafeInt<A>

So it is still the same size. Which has a difficulty associated with it,
namely:

unsigned short a = 2;
unsigned short b = 3;
int c = -3;

(a + b + c) using standard behavior emits an int with a value of 2 as will:
(a + (b + SafeInt<int>(c)))

But:
(a + (SafeInt<unsigned short>(b) + c))

Will throw. But this is actually an unusual case, so in practice you will
not see it much, and you can just document the behavior. I have explored
just increasing the size of the type, but it got to be a very horrible
problem and threatened to destroy perf.



> Then I'm saying that, since the bottom layer is a requirement for these
>> libraries, and it's also useful--and used--in several other numerical
>> techniques, it should be standardized as such (and not hidden as an
>> implementation detail as it proposed)
>>
>
To some extent, I agree. Though there is support for this in SafeInt -
there are templatized functions that will answer the general question of
whether an addition (for example) between two arbitrary types is going to
have a numerically valid result.


> I'm also saying that the bigger picture could critically affect design
>> decision even within the scope proposed. I gave the example of certified
>> arithmetic because that would suggest that a given safe_int should not
>> necessarily just throw right up front, but it could instead flag the
>> overflow and throw only when necessary, such as when casting to int. This
>> is important because if you are going to compare the overflowed result, you
>> can just return "maybe" from the comparison without throwing an exception.
>> This not only allows the client code to be *elegantly* explicit about the
>> way overflowed results affect the computation results, but it also allows
>> the library to be used in contexts where exceptions are to be avoided when
>> possible.
>>
>
We tried this, and it did not go well. Great idea, and we even implemented
it and put it into a fair bit of code, but we've since abandoned the
approach and removed uses of it. The best solution we've found so far is
the templatized, non-throwing functions.

--




------=_Part_61_25975378.1354066629621
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Thursday, November 22, 2012 1:33:38 PM UTC-8, Fernando Cacciola wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pad=
ding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1=
px; border-left-style: solid;"><div><div class=3D"gmail_quote">On Thu, Nov =
22, 2012 at 5:57 PM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"c-d6g_YCWMwJ">robertmac...@gmail.com</=
a><wbr>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;">For instance, both SafeInt's and your code *re=
quires* a primitive operation that returns the result in a larger type such=
 that it is known not to overflow. <br></blockquote></div></div></blockquot=
e><div>No, not true - for type A, B, operator op:</div><div>&nbsp;</div><di=
v>SafeInt&lt;A&gt; op B returns a SafeInt&lt;A&gt;</div><div>&nbsp;</div><d=
iv>So it is still the same size. Which has a difficulty associated with it,=
 namely:</div><div>&nbsp;</div><div>unsigned short a =3D 2;</div><div>unsig=
ned short b =3D 3;</div><div>int c =3D -3;</div><div>&nbsp;</div><div>(a + =
b + c) using standard behavior emits an int with a value of 2 as will:</div=
><div>(a + (b + SafeInt&lt;int&gt;(c)))</div><div>&nbsp;</div><div>But:</di=
v><div>(a + (SafeInt&lt;unsigned short&gt;(b) +&nbsp;c))</div><div>&nbsp;</=
div><div>Will throw. But this is actually an unusual case, so in practice y=
ou will not see it much, and you can just document the behavior. I have exp=
lored just increasing the size of the type, but it got to be a very horribl=
e problem and threatened to destroy perf.</div><div>&nbsp;</div><div>&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;"><div><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left:=
 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border=
-left-style: solid;">Then I'm saying that, since the bottom layer is a requ=
irement for these libraries, and it's also useful--and used--in several oth=
er numerical techniques, it should be standardized as such (and not hidden =
as an implementation detail as it proposed)<br></blockquote></div></div></b=
lockquote><div>&nbsp;</div><div>To some extent, I agree. Though there is su=
pport for this in SafeInt - there are templatized functions that will answe=
r the general question of whether an addition (for example) between two arb=
itrary types is going to have a numerically valid result.</div><div>&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width=
: 1px; border-left-style: solid;"><div><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: =
1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-=
left-style: solid;">

I'm also saying that the bigger picture could critically affect design deci=
sion even within the scope proposed. I gave the example of certified arithm=
etic because that would suggest that a given safe_int should not necessaril=
y just throw right up front, but it could instead flag the overflow and thr=
ow only when necessary, such as when casting to int. This is important beca=
use if you are going to compare the overflowed result, you can just return =
"maybe" from the comparison without throwing an exception. This not only al=
lows the client code to be *elegantly* explicit about the way overflowed re=
sults affect the computation results, but it also allows the library to be =
used in contexts where exceptions are to be avoided when possible.<br>

</blockquote></div></div></blockquote><div>&nbsp;</div><div>We tried this, =
and it did not go well. Great idea,&nbsp;and we even implemented it and put=
 it into a fair bit of code, but we've since abandoned the approach and&nbs=
p;removed uses&nbsp;of it. The best solution we've found so far is the temp=
latized, non-throwing functions.&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_61_25975378.1354066629621--

.

------=_Part_1290_15466777.1354068302839
Content-Type: text/plain; charset=ISO-8859-1


>
>
>>
>>
> I haven't checked your code in this corner case, but SafeInt uses a form
> of 128 bits type (when configured as such)
>

No, it does not support 128-bit integers. Once there is a compiler that
will give you those, then it could be extended. But the template
programming accounts for all 64 possible combination of signed and size
that we currently have. If you introduce a fifth, then we have a 100 node
table, and some of the current edge cases get easier, to be replaced by
edge cases because now we don't have a 256 bit type.


> So what's the signature of operator+ ( safe<int64>, safe<int64> ) ?
>

SafeInt<int64> operator+( SafeInt<int64>, SafeInt<64>)


>
> I still prefer something more general that would allow me to do:
>
> int16 a,b ;
> int32 x = safe_add(a,b);
>
> and entirely bypass the wrapper though, specially as a std utility (which
> is what we are discussing here)
>

Yes, that's included in the class, because there are times you want to test
things and not have to deal with exceptions at all. Though it has to be
done (in general) as:

int16 tmp;
if(SafeAdd(a, b, tmp) && SafeCast(tmp, x))

Because you have two operations that can possibly make trouble, though in
this case, the second will compile away, because it is always safe.


>
>
>> safe<int16> a;
>> safe<int32> b;
>>
>> auto x = a + b;  // what is the type of x?
>>
>
> should be safe<int64>
>

No, it is defined, and depends on operator precedence. This would invoke:
SafeInt<int16>::operator+(SafeInt<int32>)
which returns a SafeInt<int16>

If you wanted a SafeInt<int64> out of it, then you would write:

auto x = SafeInt<int64>(a) + b;

Else, we quickly get to all operations working on the largest possible
type, and perf would suffer badly.


>
>
>> auto x = b + a;  // is the type of y the same as the type of x?
>>
>> yes
>
Actually, no.


>
>
>> Questions like these made me decide to divide the task as you suggested
>> a) do the calculation resulting in a type which can hold the true result
>> b) on assignment or cast (safe_cast ...) trap the attempt to save a value
>> which loses information.
>>
>>
> So we are almost on the same page.
>
> We differ in how to propose two two layers to the std
>

That approach will end up being infeasible due to perf issues.


--




------=_Part_1290_15466777.1354068302839
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;"><div><br>&nbsp;</div></blockquote><div>I haven't checked you=
r code in this corner case, but SafeInt uses a form of 128 bits type (when =
configured as such)<br></div></div></div></blockquote><div>&nbsp;</div><div=
>No, it does not support 128-bit integers. Once there is a compiler that wi=
ll give you those, then it could be extended. But the template programming =
accounts for all 64 possible combination of signed and size that we current=
ly have. If you introduce a fifth, then we have a 100 node table, and some =
of the current edge cases get easier, to be replaced by edge cases because =
now we don't&nbsp;have a 256 bit type.</div><div>&nbsp;</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;"><div><div class=3D"gmail_quote"><div>So what's the signature=
 of operator+ ( safe&lt;int64&gt;, safe&lt;int64&gt; ) ?<br></div></div></d=
iv></blockquote><div>&nbsp;</div><div>SafeInt&lt;int64&gt; operator+(&nbsp;=
SafeInt&lt;int64&gt;, SafeInt&lt;64&gt;)</div><div>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex=
; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-lef=
t-style: solid;"><div><div class=3D"gmail_quote"><div>

<br>I still prefer something more general that would allow me to do:<br><br=
>int16 a,b ;<br>int32 x =3D safe_add(a,b);<br><br>and entirely bypass the w=
rapper though, specially as a std utility (which is what we are discussing =
here)<br></div></div></div></blockquote><div>&nbsp;</div><div>Yes, that's i=
ncluded in the class, because there are times you want to test things and n=
ot have to deal with exceptions at all. Though it has to be done (in genera=
l)&nbsp;as:</div><div>&nbsp;</div><div>int16&nbsp;tmp;</div><div>if(SafeAdd=
(a, b, tmp) &amp;&amp; SafeCast(tmp, x))</div><div>&nbsp;</div><div>Because=
 you have two operations that can possibly make trouble, though in this cas=
e, the second will compile away, because it is always safe.</div><div>&nbsp=
;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wid=
th: 1px; border-left-style: solid;"><div><div class=3D"gmail_quote"><div>

&nbsp;&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div>safe&lt;int16&gt; a;<br=
>safe&lt;int32&gt; b;<br><br>auto x =3D a + b;&nbsp; // what is the type of=
 x?<br>
</div>
</blockquote><div><br>should be safe&lt;int64&gt;<br></div></div></div></bl=
ockquote><div>&nbsp;</div><div>No, it is defined, and depends on operator p=
recedence. This would invoke:</div><div>SafeInt&lt;int16&gt;::operator+(Saf=
eInt&lt;int32&gt;)</div><div>which returns a SafeInt&lt;int16&gt;</div><div=
>&nbsp;</div><div>If you wanted a SafeInt&lt;int64&gt; out of it, then you =
would write:</div><div>&nbsp;</div><div>auto x =3D SafeInt&lt;int64&gt;(a) =
+ b;</div><div>&nbsp;</div><div>Else, we quickly get to all operations work=
ing on the&nbsp;largest possible type, and perf would suffer badly.</div><d=
iv>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;"><div><div class=3D"gmail_quote"=
><div>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;"><div>auto x =3D b + a;&n=
bsp; // is the type of y the same as the type of x?<br>

<br></div></blockquote><div>yes<br></div></div></div></blockquote><div>Actu=
ally, no.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;"><div><div clas=
s=3D"gmail_quote"><div>&nbsp;<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div>Qu=
estions like these made me decide to divide the task as you suggested<br>

a) do the calculation resulting in a type which can hold the true result<br=
>b) on assignment or cast (safe_cast ...) trap the attempt to save a value =
which loses information.<br><br></div></blockquote><div><br>So we are almos=
t on the same page.<br>

<br>We differ in how to propose two two layers to the std<br></div></div></=
div></blockquote><div>&nbsp;</div><div>That approach will end up being infe=
asible due to perf issues.</div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1290_15466777.1354068302839--

.

------=_Part_461_3271723.1354068612663
Content-Type: text/plain; charset=ISO-8859-1

Yes, strong agreement.

On Sunday, November 25, 2012 10:31:18 AM UTC-8, Marc Thibault wrote:

> I also believe that safe-numerics is very good. I think the problem of
> integers that grows at runtime has to be done in a different library. Also,
> there is the independent problem of creating efficient accumulators.
>
>

--




------=_Part_461_3271723.1354068612663
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Yes, strong agreement.</div><div><br>On Sunday, November 25, 2012 10:3=
1:18 AM UTC-8, Marc Thibault wrote:</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: r=
gb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">I als=
o believe that safe-numerics is very good. I think the problem of integers =
that grows at runtime has to be done in a different library. Also, there is=
 the independent problem of creating efficient accumulators.<br><br></block=
quote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_461_3271723.1354068612663--

.

--047d7b3436a27994eb04cf84ce66
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 27, 2012 at 10:37 PM, <dvd_leblanc@yahoo.com> wrote:

>
> On Thursday, November 22, 2012 1:33:38 PM UTC-8, Fernando Cacciola wrote:
>
>> On Thu, Nov 22, 2012 at 5:57 PM, <robertmac...@gmail.com**> wrote:
>>
>>> For instance, both SafeInt's and your code *requires* a primitive
>>> operation that returns the result in a larger type such that it is known
>>> not to overflow.
>>>
>> No, not true - for type A, B, operator op:
>
> SafeInt<A> op B returns a SafeInt<A>
>
>

I was referring to the implementation.
In the code (I did actually look), you do perform "the primitive operation
in a type that has twice the precision" of the operands.



> So it is still the same size. Which has a difficulty associated with it,
> namely:
>
> unsigned short a = 2;
> unsigned short b = 3;
> int c = -3;
>
> (a + b + c) using standard behavior emits an int with a value of 2 as will:
> (a + (b + SafeInt<int>(c)))
>
> But:
> (a + (SafeInt<unsigned short>(b) + c))
>
> Will throw. But this is actually an unusual case, so in practice you will
> not see it much, and you can just document the behavior. I have explored
> just increasing the size of the type, but it got to be a very horrible
> problem and threatened to destroy perf.
>
>


>
>> Then I'm saying that, since the bottom layer is a requirement for these
>>> libraries, and it's also useful--and used--in several other numerical
>>> techniques, it should be standardized as such (and not hidden as an
>>> implementation detail as it proposed)
>>>
>>
> To some extent, I agree. Though there is support for this in SafeInt -
> there are templatized functions that will answer the general question of
> whether an addition (for example) between two arbitrary types is going to
> have a numerically valid result.
>

I know. I saw them in the code.
And I'm saying that such functions (or whatever, it doesn't really matter
what it is exactly, to the effect of my point) are a bottom layer of
SafeInt but they would be equally useful as a bottom layer for several
other integer related utility classes.
Then, I propose to standarize *them* as well.


>
>
>>  I'm also saying that the bigger picture could critically affect design
>>> decision even within the scope proposed. I gave the example of certified
>>> arithmetic because that would suggest that a given safe_int should not
>>> necessarily just throw right up front, but it could instead flag the
>>> overflow and throw only when necessary, such as when casting to int. This
>>> is important because if you are going to compare the overflowed result, you
>>> can just return "maybe" from the comparison without throwing an exception.
>>> This not only allows the client code to be *elegantly* explicit about the
>>> way overflowed results affect the computation results, but it also allows
>>> the library to be used in contexts where exceptions are to be avoided when
>>> possible.
>>>
>>
> We tried this, and it did not go well. Great idea, and we even implemented
> it and put it into a fair bit of code, but we've since abandoned the
> approach and removed uses of it. The best solution we've found so far is
> the templatized, non-throwing functions.
>

Fair enough.
OTOH, I believe it is reasonable to ask for a rationale on why it did not
work, and to allow us to have some discussion about it, which would not
ignore your experience but simply try to consider different contexts which
might have not been taken into account when you first consider it.

For example, you said "Turned out to be unusable, since a simple check like
if (SafeCheckedInt<int>(x) < 0) might throw"

Why would that throw? I don't get it



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b3436a27994eb04cf84ce66
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Nov 27, 2=
012 at 10:37 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:dvd_leblanc@yahoo=
..com" target=3D"_blank">dvd_leblanc@yahoo.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">

<div class=3D"im"><br>On Thursday, November 22, 2012 1:33:38 PM UTC-8, Fern=
ando Cacciola wrote:</div><div class=3D"im"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid=
 rgb(204,204,204)">

<div><div class=3D"gmail_quote">On Thu, Nov 22, 2012 at 5:57 PM,  <span dir=
=3D"ltr">&lt;<a>robertmac...@gmail.com</a><u></u>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left:1px solid rgb(204,204,204)">For instance, both SafeIn=
t&#39;s and your code *requires* a primitive operation that returns the res=
ult in a larger type such that it is known not to overflow. <br>

</blockquote></div></div></blockquote></div><div>No, not true - for type A,=
 B, operator op:</div><div>=A0</div><div>SafeInt&lt;A&gt; op B returns a Sa=
feInt&lt;A&gt;</div><div>=A0</div></blockquote><div><br>I was referring to =
the implementation.<br>

In the code (I did actually look), you do perform &quot;the primitive opera=
tion in a type that has twice the precision&quot; of the operands.<br><br>=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div>So it is still the same size. Which has a difficulty associated with i=
t, namely:</div><div>=A0</div><div>unsigned short a =3D 2;</div><div>unsign=
ed short b =3D 3;</div><div>int c =3D -3;</div><div>=A0</div><div>(a + b + =
c) using standard behavior emits an int with a value of 2 as will:</div>

<div>(a + (b + SafeInt&lt;int&gt;(c)))</div><div>=A0</div><div>But:</div><d=
iv>(a + (SafeInt&lt;unsigned short&gt;(b) +=A0c))</div><div>=A0</div><div>W=
ill throw. But this is actually an unusual case, so in practice you will no=
t see it much, and you can just document the behavior. I have explored just=
 increasing the size of the type, but it got to be a very horrible problem =
and threatened to destroy perf.</div>

<div class=3D"im"><div>=A0</div></div></blockquote><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div class=3D"im"><div>=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-l=
eft:1ex;border-left:1px solid rgb(204,204,204)">

<div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204=
,204)">Then I&#39;m saying that, since the bottom layer is a requirement fo=
r these libraries, and it&#39;s also useful--and used--in several other num=
erical techniques, it should be standardized as such (and not hidden as an =
implementation detail as it proposed)<br>

</blockquote></div></div></blockquote><div>=A0</div></div><div>To some exte=
nt, I agree. Though there is support for this in SafeInt - there are templa=
tized functions that will answer the general question of whether an additio=
n (for example) between two arbitrary types is going to have a numerically =
valid result.</div>

<div class=3D"im"><div></div></div></blockquote><div><br>I know. I saw them=
 in the code.<br>And I&#39;m saying that such functions (or whatever, it do=
esn&#39;t really matter what it is exactly, to the effect of my point) are =
a bottom layer of SafeInt but they would be equally useful as a bottom laye=
r for several other integer related utility classes.<br>

Then, I propose to standarize *them* as well.<br>=A0<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div class=3D"im"><div>=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:=
1ex;border-left:1px solid rgb(204,204,204)">

<div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204=
,204)">

I&#39;m also saying that the bigger picture could critically affect design =
decision even within the scope proposed. I gave the example of certified ar=
ithmetic because that would suggest that a given safe_int should not necess=
arily just throw right up front, but it could instead flag the overflow and=
 throw only when necessary, such as when casting to int. This is important =
because if you are going to compare the overflowed result, you can just ret=
urn &quot;maybe&quot; from the comparison without throwing an exception. Th=
is not only allows the client code to be *elegantly* explicit about the way=
 overflowed results affect the computation results, but it also allows the =
library to be used in contexts where exceptions are to be avoided when poss=
ible.<br>



</blockquote></div></div></blockquote><div>=A0</div></div><div>We tried thi=
s, and it did not go well. Great idea,=A0and we even implemented it and put=
 it into a fair bit of code, but we&#39;ve since abandoned the approach and=
=A0removed uses=A0of it. The best solution we&#39;ve found so far is the te=
mplatized, non-throwing functions.=A0</div>

</blockquote><div><br>Fair enough. <br>OTOH, I believe it is reasonable to =
ask for a rationale on why it did not work, and to allow us to have some di=
scussion about it, which would not ignore your experience but simply try to=
 consider different contexts which might have not been taken into account w=
hen you first consider it.<br>

<br>For example, you said &quot;Turned out to be unusable, since a simple c=
heck like if (SafeCheckedInt&lt;int&gt;(x) &lt; 0) might throw&quot;<br><br=
>Why would that throw? I don&#39;t get it<br></div></div><br><br clear=3D"a=
ll">

<br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"h=
ttp://www.scisoft-consulting.com">http://www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3436a27994eb04cf84ce66--

.

------=_Part_1213_22925733.1354069507195
Content-Type: text/plain; charset=ISO-8859-1


On Tuesday, November 27, 2012 5:33:03 AM UTC-8, Fernando Cacciola wrote:
>
>
> On Mon, Nov 26, 2012 at 1:59 PM, Ben Craig <ben....@gmail.com<javascript:>
> > wrote:
>
>> Some large use cases for SafeInt are computing sizes for buffers and
>> array indices.
>
>
> Hmmm.
> Can you elaborate how is SafeInt safe when it comes to an array index in
> the case of an array of runtime size? Which I believe is, by far, the most
> common type of array (buffer, container, etc)
>

We can ensure that the array index is not the result of a wrapping
operation. If you want to ensure that the index is within the bounds of the
array, then I would construct the array from std::vector, and then rely on
either at() or [] to know what is a suitable range. Works better if someone
comes along and resizes the array while your other variable is not updated.


>
> For *that* purpose I think the proper tool is an integer with runtime
> boundaries (a number of these have been implemented and proposed to, for
> instance, Boost)
>
Disagree - then you have to keep the boundaries in sync with the buffer
size, which could grow or shrink, and the code may not think to notify the
bounds. Especially given that the most efficient way to implement the
bounds would be at compile time, and then you are stuck.



>   In these situations, you probably want to throw an exception, or
>> terminate the program.
>
>
> This s off-topic but IMO you never ever want to terminate a program when
> you use a language that supports exceptions, like C++
>
>
Also disagree. You may be in a state where you cannot cleanly unwind.
Clearly, if you have ideal C++ code, then you can, but I have not seen much
ideal code in the wild. You may want to just consider it the same sort of
problem as a bad pointer dereference where you just take the app down. This
is why the exception policy for SafeInt is user-defined, and you could have
your own custom exceptions, standard exceptions, fail fast to exit, or
OS-specific error handlers.


>
>

--




------=_Part_1213_22925733.1354069507195
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Tuesday, November 27, 2012 5:33:03 AM UTC-8, Fernando Cacciola wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><div><br><div class=3D"gmail_quote">On Mon, N=
ov 26, 2012 at 1:59 PM, Ben Craig <span dir=3D"ltr">&lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"m2iiPDmoMCUJ">ben....@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204=
, 204); border-left-width: 1px; border-left-style: solid;">

Some large use cases for SafeInt are computing sizes for buffers and array =
indices.</blockquote><div><br>Hmmm.<br>Can you elaborate how is SafeInt saf=
e when it comes to an array index in the case of an array of runtime size? =
Which I believe is, by far, the most common type of array (buffer, containe=
r, etc)<br></div></div></div></blockquote><div>&nbsp;</div><div>We&nbsp;can=
 ensure that the array index is not the result of a wrapping operation. If =
you want to ensure that the index is within the&nbsp;bounds of the array, t=
hen I would construct the array from std::vector, and then rely&nbsp;on eit=
her at() or [] to know what is a suitable range. Works better if someone co=
mes along and resizes the array while your other variable is not updated.</=
div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;"><div><div class=3D"gmail_=
quote"><div>

<br>For *that* purpose I think the proper tool is an integer with runtime b=
oundaries (a number of these have been implemented and proposed to, for ins=
tance, Boost)<br></div></div></div></blockquote><div>Disagree - then you ha=
ve to keep the boundaries in sync with the buffer size, which could grow or=
 shrink, and the code may not think to notify the bounds. Especially given =
that the most efficient way to implement the bounds would be at compile tim=
e, and then you are stuck.</div><div>&nbsp;<br>&nbsp;</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bo=
rder-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-st=
yle: solid;"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-colo=
r: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">

&nbsp; In these situations, you probably want to throw an exception, or ter=
minate the program.&nbsp;</blockquote><div><br>This s off-topic but IMO you=
 never ever want to terminate a program when you use a language that suppor=
ts exceptions, like C++<br>

<br></div></div></div></blockquote><div>&nbsp;</div><div>Also disagree. You=
 may be in a state where you cannot cleanly unwind. Clearly, if you have id=
eal C++ code, then you can, but I have not seen much ideal code in the wild=
.. You may want to just consider it the same sort of problem as a bad pointe=
r dereference where you just take the app down. This is why the exception p=
olicy for SafeInt is user-defined, and you could have your own custom excep=
tions, standard exceptions, fail fast to exit, or OS-specific error handler=
s.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div><div class=3D"gm=
ail_quote"><div>&nbsp;</div></div>
</div>
</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1213_22925733.1354069507195--

.

--047d7b34372c9bc17a04cf84fc9d
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 27, 2012 at 11:05 PM, <dvd_leblanc@yahoo.com> wrote:

>
>>>
>>>
>> I haven't checked your code in this corner case, but SafeInt uses a form
>> of 128 bits type (when configured as such)
>>
>
> No, it does not support 128-bit integers.
>

Not on the interface.
But the code uses _imul128 (or some such) for a certain operation over
certain argument and given certain configuration options.

So the implementation is using an operation on 128 integers.



> Once there is a compiler that will give you those, then it could be
> extended. But the template programming accounts for all 64 possible
> combination of signed and size that we currently have. If you introduce a
> fifth, then we have a 100 node table, and some of the current edge cases
> get easier, to be replaced by edge cases because now we don't have a 256
> bit type.
>
>
>> So what's the signature of operator+ ( safe<int64>, safe<int64> ) ?
>>
>
> SafeInt<int64> operator+( SafeInt<int64>, SafeInt<64>)
>
>
That's in you library, I know.
But that question was addressed to Robert. His library *sifnificantly*
differs from yours in this regard:


In Robert's library, safe<T> * safe<T> -> safe<2T>

And I believe *that* is the correct choice (SafeInt<> does the opposite so
I believe that's not the correct choice)

Given that pattern, I ask what's the case when you already reached int64.


>> I still prefer something more general that would allow me to do:
>>
>> int16 a,b ;
>> int32 x = safe_add(a,b);
>>
>> and entirely bypass the wrapper though, specially as a std utility (which
>> is what we are discussing here)
>>
>
> Yes, that's included in the class, because there are times you want to
> test things and not have to deal with exceptions at all. Though it has to
> be done (in general) as:
>
> int16 tmp;
> if(SafeAdd(a, b, tmp) && SafeCast(tmp, x))
>
>
I know.
And I would use a totally different *interface* but that's minor. What
matters IMO is the existence of these utilities, which I believe should not
be left hidden in the implementation.



> Because you have two operations that can possibly make trouble, though in
> this case, the second will compile away, because it is always safe.
>
>
>>
>>
>>> safe<int16> a;
>>> safe<int32> b;
>>>
>>> auto x = a + b;  // what is the type of x?
>>>
>>
>> should be safe<int64>
>>
>
> No, it is defined, and depends on operator precedence. This would invoke:
> SafeInt<int16>::operator+(SafeInt<int32>)
> which returns a SafeInt<int16>
>
>
In your library, yes.

In Robert's, it does not need to return a safe-int of the same type. Hence,
it *shoukld* return a safe of the next bigger type, int64 in this case.


> If you wanted a SafeInt<int64> out of it, then you would write:
>
> auto x = SafeInt<int64>(a) + b;
>
> Else, we quickly get to all operations working on the largest possible
> type, and perf would suffer badly.
>
>
OK.
Then that would be your argument for NOT automatically promoting to the
next bigger type to avoid overflow.

Right off the top of my head I disagree with your conclusion (I agree with
the perf observation but not the conclusion you drew from that), but this
is one thing that should be discussed as its own topic.



>
>>
>>> auto x = b + a;  // is the type of y the same as the type of x?
>>>
>>> yes
>>
> Actually, no.
>
>
Maybe one of us is misreading the question.

I read the question as: Should ( a + b ) and ( b + a) return the same type?

I say yes.



>
>>
>>> Questions like these made me decide to divide the task as you suggested
>>> a) do the calculation resulting in a type which can hold the true result
>>> b) on assignment or cast (safe_cast ...) trap the attempt to save a
>>> value which loses information.
>>>
>>>
>> So we are almost on the same page.
>>
>> We differ in how to propose two two layers to the std
>>
>
> That approach will end up being infeasible due to perf issues.
>
>
I would need you to elaborate on that.



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b34372c9bc17a04cf84fc9d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Nov 27, 2=
012 at 11:05 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:dvd_leblanc@yahoo=
..com" target=3D"_blank">dvd_leblanc@yahoo.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">

<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-=
width:1px;border-left-style:solid"><div><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1e=
x;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-styl=
e:solid">

<div><br>=A0</div></blockquote><div>I haven&#39;t checked your code in this=
 corner case, but SafeInt uses a form of 128 bits type (when configured as =
such)<br></div></div></div></blockquote><div>=A0</div></div><div>No, it doe=
s not support 128-bit integers.</div>

</blockquote><div><br>Not on the interface.<br>But the code uses _imul128 (=
or some such) for a certain operation over certain argument and given certa=
in configuration options.<br><br>So the implementation is using an operatio=
n on 128 integers.<br>

<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div> Once there is a compiler =
that will give you those, then it could be extended. But the template progr=
amming accounts for all 64 possible combination of signed and size that we =
currently have. If you introduce a fifth, then we have a 100 node table, an=
d some of the current edge cases get easier, to be replaced by edge cases b=
ecause now we don&#39;t=A0have a 256 bit type.</div>

<div class=3D"im"><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div><div class=3D"gmail_q=
uote">

<div>So what&#39;s the signature of operator+ ( safe&lt;int64&gt;, safe&lt;=
int64&gt; ) ?<br></div></div></div></blockquote><div>=A0</div></div><div>Sa=
feInt&lt;int64&gt; operator+(=A0SafeInt&lt;int64&gt;, SafeInt&lt;64&gt;)</d=
iv>

<div class=3D"im"><div>=A0</div></div></blockquote><div>That&#39;s in you l=
ibrary, I know.<br>But that question was addressed to Robert. His library *=
sifnificantly* differs from yours in this regard:<br><br><br>In Robert&#39;=
s library, safe&lt;T&gt; * safe&lt;T&gt; -&gt; safe&lt;2T&gt;<br>

<br>And I believe *that* is the correct choice (SafeInt&lt;&gt; does the op=
posite so I believe that&#39;s not the correct choice)<br><br>Given that pa=
ttern, I ask what&#39;s the case when you already reached int64.<br><br>

</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-lef=
t-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">

<div><div class=3D"gmail_quote"><div>

<br>I still prefer something more general that would allow me to do:<br><br=
>int16 a,b ;<br>int32 x =3D safe_add(a,b);<br><br>and entirely bypass the w=
rapper though, specially as a std utility (which is what we are discussing =
here)<br>

</div></div></div></blockquote><div>=A0</div></div><div>Yes, that&#39;s inc=
luded in the class, because there are times you want to test things and not=
 have to deal with exceptions at all. Though it has to be done (in general)=
=A0as:</div>

<div>=A0</div><div>int16=A0tmp;</div><div>if(SafeAdd(a, b, tmp) &amp;&amp; =
SafeCast(tmp, x))</div><div>=A0</div></blockquote><div>I know.<br>And I wou=
ld use a totally different *interface* but that&#39;s minor. What matters I=
MO is the existence of these utilities, which I believe should not be left =
hidden in the implementation.<br>

<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div>Because you have two opera=
tions that can possibly make trouble, though in this case, the second will =
compile away, because it is always safe.</div>

<div class=3D"im"><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div><div class=3D"gmail_q=
uote">

<div>

=A0=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:=
1px;border-left-style:solid"><div>safe&lt;int16&gt; a;<br>safe&lt;int32&gt;=
 b;<br>

<br>auto x =3D a + b;=A0 // what is the type of x?<br>
</div>
</blockquote><div><br>should be safe&lt;int64&gt;<br></div></div></div></bl=
ockquote><div>=A0</div></div><div>No, it is defined, and depends on operato=
r precedence. This would invoke:</div><div>SafeInt&lt;int16&gt;::operator+(=
SafeInt&lt;int32&gt;)</div>

<div>which returns a SafeInt&lt;int16&gt;</div><div>=A0</div></blockquote><=
div>In your library, yes.<br><br>In Robert&#39;s, it does not need to retur=
n a safe-int of the same type. Hence, it *shoukld* return a safe of the nex=
t bigger type, int64 in this case.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div>If you wanted a SafeInt&lt=
;int64&gt; out of it, then you would write:</div><div>=A0</div><div>auto x =
=3D SafeInt&lt;int64&gt;(a) + b;</div>

<div>=A0</div><div>Else, we quickly get to all operations working on the=A0=
largest possible type, and perf would suffer badly.</div><div class=3D"im">=
<div>=A0</div></div></blockquote><div>OK.<br>Then that would be your argume=
nt for NOT automatically promoting to the next bigger type to avoid overflo=
w.<br>

<br>Right off the top of my head I disagree with your conclusion (I agree w=
ith the perf observation but not the conclusion you drew from that), but th=
is is one thing that should be discussed as its own topic.<br><br>=A0 <br>

</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-lef=
t-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">

<div><div class=3D"gmail_quote"><div>=A0<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-col=
or:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div>aut=
o x =3D b + a;=A0 // is the type of y the same as the type of x?<br>



<br></div></blockquote><div>yes<br></div></div></div></blockquote></div><di=
v>Actually, no.</div><div class=3D"im"><div>=A0</div></div></blockquote><di=
v>Maybe one of us is misreading the question.<br><br>I read the question as=
: Should ( a + b ) and ( b + a) return the same type?<br>

<br>I say yes.<br><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D=
"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bor=
der-left-style:solid">

<div><div class=3D"gmail_quote"><div>=A0<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-col=
or:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div>Que=
stions like these made me decide to divide the task as you suggested<br>



a) do the calculation resulting in a type which can hold the true result<br=
>b) on assignment or cast (safe_cast ...) trap the attempt to save a value =
which loses information.<br><br></div></blockquote><div><br>So we are almos=
t on the same page.<br>



<br>We differ in how to propose two two layers to the std<br></div></div></=
div></blockquote><div>=A0</div></div><div>That approach will end up being i=
nfeasible due to perf issues.</div><span class=3D"HOEnZb"><font color=3D"#8=
88888"><div>

=A0</div></font></span></blockquote><div>I would need you to elaborate on t=
hat.<br><br>=A0<br></div></div><br>-- <br>Fernando Cacciola<br>SciSoft Cons=
ulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">http://www=
..scisoft-consulting.com</a><br>


</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b34372c9bc17a04cf84fc9d--

.

--047d7b621ede881cf704cf851b14
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 27, 2012 at 11:25 PM, <dvd_leblanc@yahoo.com> wrote:

>
> On Tuesday, November 27, 2012 5:33:03 AM UTC-8, Fernando Cacciola wrote:
>
>>
>> On Mon, Nov 26, 2012 at 1:59 PM, Ben Craig <ben....@gmail.com> wrote:
>>
>>> Some large use cases for SafeInt are computing sizes for buffers and
>>> array indices.
>>
>>
>> Hmmm.
>> Can you elaborate how is SafeInt safe when it comes to an array index in
>> the case of an array of runtime size? Which I believe is, by far, the most
>> common type of array (buffer, container, etc)
>>
>
> We can ensure that the array index is not the result of a wrapping
> operation. If you want to ensure that the index is within the bounds of the
> array, then I would construct the array from std::vector, and then rely on
> either at() or [] to know what is a suitable range. Works better if someone
> comes along and resizes the array while your other variable is not updated.
>
>
Right, I totally misunderstood the index example.
That was clarified and I then agreed that a safe-int is very useful for
that.


>> For *that* purpose I think the proper tool is an integer with runtime
>> boundaries (a number of these have been implemented and proposed to, for
>> instance, Boost)
>>
> Disagree - then you have to keep the boundaries in sync with the buffer
> size, which could grow or shrink, and the code may not think to notify the
> bounds. Especially given that the most efficient way to implement the
> bounds would be at compile time, and then you are stuck.
>
>
I agree with your disagreement. I propose that to a problem I thought you
where solving based on my (mis)interpretation of the example. But of course
I don't think you should do that (just that if you do that, do it with the
right type of wrapper)



>
>
>>    In these situations, you probably want to throw an exception, or
>>> terminate the program.
>>
>>
>> This s off-topic but IMO you never ever want to terminate a program when
>> you use a language that supports exceptions, like C++
>>
>>
> Also disagree. You may be in a state where you cannot cleanly unwind.
> Clearly, if you have ideal C++ code, then you can, but I have not seen much
> ideal code in the wild. You may want to just consider it the same sort of
> problem as a bad pointer dereference where you just take the app down.
>

FWIW I don't take the app down in the presence of a bad-pointer.
Neither do the most popular application frameworks, like .Net for instance.



> This is why the exception policy for SafeInt is user-defined, and you
> could have your own custom exceptions, standard exceptions, fail fast to
> exit, or OS-specific error handlers.
>
>
Then you actually agree. In my sentence, "you" is the library
implementation. A policy is in the hand of the application (assuming a well
engineered one),  and of course "it" can terminate  the program or do
whatever. It is the *library* which cannot do that.





--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b621ede881cf704cf851b14
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Tue, Nov 27, 2012 =
at 11:25 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:dvd_leblanc@yahoo.com=
" target=3D"_blank">dvd_leblanc@yahoo.com</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">

<br>On Tuesday, November 27, 2012 5:33:03 AM UTC-8, Fernando Cacciola wrote=
:<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left=
-width:1px;border-left-style:solid">

<div><br><div class=3D"gmail_quote">On Mon, Nov 26, 2012 at 1:59 PM, Ben Cr=
aig <span dir=3D"ltr">&lt;<a>ben....@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-le=
ft:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left=
-style:solid">



Some large use cases for SafeInt are computing sizes for buffers and array =
indices.</blockquote><div><br>Hmmm.<br>Can you elaborate how is SafeInt saf=
e when it comes to an array index in the case of an array of runtime size? =
Which I believe is, by far, the most common type of array (buffer, containe=
r, etc)<br>

</div></div></div></blockquote><div>=A0</div></div><div>We=A0can ensure tha=
t the array index is not the result of a wrapping operation. If you want to=
 ensure that the index is within the=A0bounds of the array, then I would co=
nstruct the array from std::vector, and then rely=A0on either at() or [] to=
 know what is a suitable range. Works better if someone comes along and res=
izes the array while your other variable is not updated.</div>

<div class=3D"im"><div>=A0</div></div></blockquote><div>Right, I totally mi=
sunderstood the index example.<br>That was clarified and I then agreed that=
 a safe-int is very useful for that.<br><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">

<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-=
width:1px;border-left-style:solid"><div><div class=3D"gmail_quote"><div>

<br>For *that* purpose I think the proper tool is an integer with runtime b=
oundaries (a number of these have been implemented and proposed to, for ins=
tance, Boost)<br></div></div></div></blockquote></div><div>Disagree - then =
you have to keep the boundaries in sync with the buffer size, which could g=
row or shrink, and the code may not think to notify the bounds. Especially =
given that the most efficient way to implement the bounds would be at compi=
le time, and then you are stuck.</div>

<div class=3D"im"><div>=A0<br></div></div></blockquote><div>I agree with yo=
ur disagreement. I propose that to a problem I thought you where solving ba=
sed on my (mis)interpretation of the example. But of course I don&#39;t thi=
nk you should do that (just that if you do that, do it with the right type =
of wrapper)<br>

<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"><div>=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bor=
der-left-style:solid">

<div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid">

=A0 In these situations, you probably want to throw an exception, or termin=
ate the program.=A0</blockquote><div><br>This s off-topic but IMO you never=
 ever want to terminate a program when you use a language that supports exc=
eptions, like C++<br>



<br></div></div></div></blockquote><div>=A0</div></div><div>Also disagree. =
You may be in a state where you cannot cleanly unwind. Clearly, if you have=
 ideal C++ code, then you can, but I have not seen much ideal code in the w=
ild. You may want to just consider it the same sort of problem as a bad poi=
nter dereference where you just take the app down. </div>

</blockquote><div><br>FWIW I don&#39;t take the app down in the presence of=
 a bad-pointer.<br>Neither do the most popular application frameworks, like=
 .Net for instance.<br><br>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>This is why the exception policy for SafeInt is user-defined, and you =
could have your own custom exceptions, standard exceptions, fail fast to ex=
it, or OS-specific error handlers.</div><div>=A0</div></blockquote><div>
Then you actually agree. In my sentence, &quot;you&quot; is the library imp=
lementation. A policy is in the hand of the application (assuming a well en=
gineered one),=A0 and of course &quot;it&quot; can terminate=A0 the program=
 or do whatever. It is the *library* which cannot do that.<br>

<br><br></div></div><br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>S=
ciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com"=
>http://www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b621ede881cf704cf851b14--

.

------=_Part_395_354477.1354070511413
Content-Type: text/plain; charset=ISO-8859-1


On Tuesday, November 27, 2012 5:44:44 AM UTC-8, Fernando Cacciola wrote:
>
>
>
>>
>>
> Hmm, how isn't is as simple as using a software-based int128 number type?
>
>

Depends on the operation, and I was not aware of a software-based 128-bit
type at the time. You might not need it - for example, unsigned addition is
well defined, and we can check the result more cheaply. Where this would
come in handy is 64-bit multiplication, which is a sticky problem.

>> Now suppose you change all the 'int' for safe<int> and you discover a
point where overflow is occurring?  What do you do?
By analogy to the div-by-zero case, and IME (and I do have experience
writing algorithms that need handle overflow, both integer and
floating-point), you also want to detect the case before-hand so you can do
something else.

You can still do this.

>> Wait.
Numerical overflow is *rarely* a programming error. It's the consequence of
finite precision when crunching numbers.

OK, so a light just came on - you are thinking of this in terms of
numerical analysis, which has very different needs than ordinary production
software where we're only calculating offsets and the argument to malloc
for the most part. I would in general not suggest using SafeInt for that
sort of application. It would probably ruin your perf. It might be a great
tool for debugging to see just why you're coming up with odd results.

When we're dealing with the types of patterns seen from within general use
software, numerical overflow is almost always unintended, and often results
in disaster. Here's an example of how you can get real mayhem (and no true
overflow involved)

char* p1 = Init1();
char* p2 = Init2();
unsigned int max = some_const;

if (p2 - p1 < max)
  DoThis();
else
  DoThat();

Now consider the case of p1 > p2, yielding a negative result. The type of
(p2 -p1) is ptrdiff_t. When we compile this on a 32-bit system, the
ptrdiff_t will cast to unsigned long, and we will call DoThat(). If we have
a 64-bit system, and int is 32-bit, then max is cast to ptrdiff_t, and we
will call DoThis(), which is almost certainly not intended.

It may be the consequence of finite precision, but it leads to a lot of
security exploits.



--




------=_Part_395_354477.1354070511413
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Tuesday, November 27, 2012 5:44:44 AM UTC-8, Fernando Cacciola wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><div><br><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: =
1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-=
left-style: solid;"><div><br>&nbsp;</div></blockquote><div>Hmm, how isn't i=
s as simple as using a software-based int128 number type?<br>&nbsp;<br></di=
v></div></div></blockquote><div>&nbsp;</div><div>Depends on the operation, =
and I was not aware of a software-based 128-bit type at the time. You might=
 not need it - for example, unsigned addition is well defined, and we can c=
heck&nbsp;the result more cheaply. Where this would come in handy is 64-bit=
 multiplication, which is a sticky problem.</div><div><br>&gt;&gt; Now supp=
ose you change all the 'int' for safe&lt;int&gt; and you discover a point w=
here overflow is occurring?&nbsp; What do you do?<br>

By analogy to the div-by-zero case, and IME (and I do have experience writi=
ng algorithms that need handle overflow, both integer and floating-point), =
you also want to detect the case before-hand so you can do something else. =
</div><div>&nbsp;</div><div>You can still do this.</div><div><br>

&gt;&gt; Wait.<br>Numerical overflow is *rarely* a programming error. It's =
the consequence of finite precision when crunching numbers.</div><div>&nbsp=
;</div><div>OK, so a light just came on - you are thinking of this in terms=
 of numerical analysis, which has very different needs than ordinary produc=
tion software where we're only calculating offsets and the argument to mall=
oc for the most part. I would in general not suggest using SafeInt for that=
 sort of application. It would probably ruin your perf. It might be a great=
 tool for debugging to see just why you're coming up with odd results.</div=
><div>&nbsp;</div><div>When we're dealing with the types of patterns seen f=
rom within general use software, numerical overflow is almost always uninte=
nded, and often results in disaster. Here's an example of how you can get r=
eal mayhem (and no true overflow involved)</div><div>&nbsp;</div><div>char*=
 p1 =3D Init1();</div><div>char* p2 =3D Init2();</div><div>unsigned&nbsp;in=
t max =3D some_const;</div><div>&nbsp;</div><div>if (p2 - p1 &lt; max)</div=
><div>&nbsp; DoThis();</div><div>else</div><div>&nbsp; DoThat();</div><div>=
&nbsp;</div><div>Now consider the case of p1 &gt; p2, yielding a negative r=
esult. The type of (p2 -p1) is ptrdiff_t. When we compile this on a 32-bit =
system, the ptrdiff_t will cast to unsigned long, and we will call DoThat()=
.. If we have a 64-bit system, and int is 32-bit, then max is cast to ptrdif=
f_t, and we will call DoThis(), which is almost certainly not intended.</di=
v><div>&nbsp;</div><div>It may be the consequence of finite precision, but =
it leads to a lot of security exploits.</div><div><br>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_395_354477.1354070511413--

.

------=_Part_115_11330772.1354071036088
Content-Type: text/plain; charset=ISO-8859-1


On Tuesday, November 27, 2012 9:43:28 AM UTC-8, Fernando Cacciola wrote:
>
>
> I'm tempted to respond, but I think this thread is not the correct place.
> (and I'm not sure where would be)
>
> Anyway, let me just rephrase that: IMO, the *end user* never ever wants
> you the programmer to structure the program in such a way that the *entire
> application* must abort as opposed to the current "task" (task from the end
> user POV )
>
> Somewhat off-topic, and very much platform-centric, but actually we do
want that under a number of conditions. On Windows, if the app aborts
unexpectedly, and you have opted in to the crash reporting feature, we then
get a bug with a stack trace and possibly a dump. If we see many of them,
we'll fix it. If you just catch the exception, then maybe we find out,
maybe we don't, and the bug is more likely to stay there. Also some
applications, Excel being one example, feel like the worst thing we can
ever do is to corrupt the user's data. Crashing is bad, but not the worst
thing we can possibly do. So if Excel gets off in the weeds, it would
rather fall over than corrupt your data.

I did once have the X Window library do that to me (call exit()), and it
was seriously annoying. So what you want is for the developer to decide
what happens, which is what SafeInt does.

--




------=_Part_115_11330772.1354071036088
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Tuesday, November 27, 2012 9:43:28 AM UTC-8, Fernando Cacciola wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><div><div class=3D"gmail_quote"><div><br>I'm =
tempted to respond, but I think this thread is not the correct place. (and =
I'm not sure where would be)<br><br>Anyway, let me just rephrase that: IMO,=
 the *end user* never ever wants you the programmer to structure the progra=
m in such a way that the *entire application* must abort as opposed to the =
current "task" (task from the end user POV )<br>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-=
width: 1px; border-left-style: solid;"><span><font color=3D"#888888">
</font></span></blockquote></div></div></blockquote><div>Somewhat off-topic=
, and very much platform-centric, but actually we do want that under&nbsp;a=
 number of conditions. On Windows, if the app aborts unexpectedly, and you =
have opted in to the&nbsp;crash reporting feature, we then get a bug with a=
 stack trace and possibly a dump. If we see many of them, we'll fix it. If =
you just catch the exception, then maybe we find out, maybe we don't, and t=
he bug is more likely to stay there. Also some applications, Excel being on=
e example, feel like the worst thing we can ever do is to corrupt the user'=
s data. Crashing is bad, but not the worst thing we can possibly do. So if =
Excel gets off in the weeds, it would rather fall over than corrupt your da=
ta.</div><div>&nbsp;</div><div>I did once have the X Window&nbsp;library do=
 that to me (call exit()), and it was seriously annoying. So what you want =
is for the developer to decide what happens, which is&nbsp;what SafeInt doe=
s.&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_115_11330772.1354071036088--

.

------=_Part_1223_19113239.1354071670710
Content-Type: text/plain; charset=ISO-8859-1


On Tuesday, November 27, 2012 6:19:32 PM UTC-8, Fernando Cacciola wrote:
>
>
>
> I was referring to the implementation.
> In the code (I did actually look), you do perform "the primitive operation
> in a type that has twice the precision" of the operands.
>
> Oh - OK. This is not always true, though. Addition can be checked without
larger types, and sometimes I just leverage normal operator casting
behavior - char op char does not go to short, but instead int. For
multiplication, this is the case for 32-bit types.

>
>
>>
>>
> To some extent, I agree. Though there is support for this in SafeInt -
>> there are templatized functions that will answer the general question of
>> whether an addition (for example) between two arbitrary types is going to
>> have a numerically valid result.
>>
>
> I know. I saw them in the code.
> And I'm saying that such functions (or whatever, it doesn't really matter
> what it is exactly, to the effect of my point) are a bottom layer of
> SafeInt but they would be equally useful as a bottom layer for several
> other integer related utility classes.
> Then, I propose to standarize *them* as well.
>
Thanks, then yes, we agree on that. However, you would need both throwing
and non-throwing semantics, as you see in the code. The throwing semantics
can sometimes have a cleaner failure path.


>
>
>> We tried this, and it did not go well. Great idea, and we even
>> implemented it and put it into a fair bit of code, but we've since
>> abandoned the approach and removed uses of it. The best solution we've
>> found so far is the templatized, non-throwing functions.
>>
>
> Fair enough.
> OTOH, I believe it is reasonable to ask for a rationale on why it did not
> work, and to allow us to have some discussion about it, which would not
> ignore your experience but simply try to consider different contexts which
> might have not been taken into account when you first consider it.
>
> For example, you said "Turned out to be unusable, since a simple check
> like if (SafeCheckedInt<int>(x) < 0) might throw"
>
>
Why would that throw? I don't get it
>

If the checked int had overflowed, then we cannot answer the question of
whether it is < 0, because it is undefined. Only thing we can do is throw
at that point. This tends to cause serious problems when trying to use it
in existing code.

I'm certainly willing to discuss the idea - one possibility is that our
implementation or design was bad. Some other approach might work. We
originally liked the idea because a float can tell us if it has become an
undefined value, seemed like this concept should transfer. Part of it was
confusion because a SafeInt can never become invalid, and a comparison
operation can never throw. So introducing something that acts somewhat the
same, but throws in places the other cannot was a mess.


>
>

--




------=_Part_1223_19113239.1354071670710
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Tuesday, November 27, 2012 6:19:32 PM UTC-8, Fernando Cacciola wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><div><br><br>I was referring to the implement=
ation.<br>

In the code (I did actually look), you do perform "the primitive operation =
in a type that has twice the precision" of the operands.<br><br></div></blo=
ckquote><div>Oh - OK. This is not&nbsp;always true, though. Addition can be=
 checked without larger types, and sometimes I just leverage normal operato=
r casting behavior - char op char does not go to short, but instead int. Fo=
r multiplication, this is the case for 32-bit types.&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div>&nbsp;<br><div class=3D"gmail_quote"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; b=
order-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-s=
tyle: solid;">

<div>&nbsp;</div></blockquote><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204=
, 204); border-left-width: 1px; border-left-style: solid;"><div>To some ext=
ent, I agree. Though there is support for this in SafeInt - there are templ=
atized functions that will answer the general question of whether an additi=
on (for example) between two arbitrary types is going to have a numerically=
 valid result.</div>

<div><div></div></div></blockquote><div><br>I know. I saw them in the code.=
<br>And I'm saying that such functions (or whatever, it doesn't really matt=
er what it is exactly, to the effect of my point) are a bottom layer of Saf=
eInt but they would be equally useful as a bottom layer for several other i=
nteger related utility classes.<br>

Then, I propose to standarize *them* as well.<br></div></div></div></blockq=
uote><div>Thanks, then yes, we agree on that. However, you would need both =
throwing and non-throwing semantics, as you see in the code. The throwing s=
emantics can sometimes have a&nbsp;cleaner failure path.</div><div>&nbsp;</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
 1px; border-left-style: solid;"><div><div class=3D"gmail_quote"><div>&nbsp=
;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wid=
th: 1px; border-left-style: solid;"><div>We tried this, and it did not go w=
ell. Great idea,&nbsp;and we even implemented it and put it into a fair bit=
 of code, but we've since abandoned the approach and&nbsp;removed uses&nbsp=
;of it. The best solution we've found so far is the templatized, non-throwi=
ng functions.&nbsp;</div>

</blockquote><div><br>Fair enough. <br>OTOH, I believe it is reasonable to =
ask for a rationale on why it did not work, and to allow us to have some di=
scussion about it, which would not ignore your experience but simply try to=
 consider different contexts which might have not been taken into account w=
hen you first consider it.<br>

<br>For example, you said "Turned out to be unusable, since a simple check =
like if (SafeCheckedInt&lt;int&gt;(x) &lt; 0) might throw"<br>&nbsp;</div><=
/div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;"><div><div class=3D"gma=
il_quote"><div>Why would that throw? I don't get it<br></div></div></div></=
blockquote><div>&nbsp;</div><div>If&nbsp;the checked int had overflowed, th=
en we cannot answer the question of whether it is&nbsp;&lt; 0, because it i=
s undefined. Only thing we can do is throw at that point. This tends to cau=
se serious problems when trying to use it in existing code.</div><div>&nbsp=
;</div><div>I'm certainly willing to discuss the idea - one possibility is =
that our implementation or design was bad. Some other approach might work. =
We originally liked the idea because a float can tell us if it has become a=
n undefined value, seemed like this concept should transfer. Part of it was=
 confusion because a SafeInt can never become invalid, and a comparison ope=
ration can never throw. So introducing something that acts somewhat the sam=
e, but throws in places the other cannot was a mess.</div><div>&nbsp;</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div><div class=3D"gmail_quote">&nbsp;</div></=
div>
</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1223_19113239.1354071670710--

.

--047d7b6242b66d619104cf8565f4
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 27, 2012 at 11:50 PM, <dvd_leblanc@yahoo.com> wrote:

>
> On Tuesday, November 27, 2012 9:43:28 AM UTC-8, Fernando Cacciola wrote:
>>
>>
>> I'm tempted to respond, but I think this thread is not the correct place.
>> (and I'm not sure where would be)
>>
>> Anyway, let me just rephrase that: IMO, the *end user* never ever wants
>> you the programmer to structure the program in such a way that the *entire
>> application* must abort as opposed to the current "task" (task from the end
>> user POV )
>>
>> Somewhat off-topic, and very much platform-centric, but actually we do
> want that under a number of conditions. On Windows, if the app aborts
> unexpectedly, and you have opted in to the crash reporting feature, we then
> get a bug with a stack trace and possibly a dump. If we see many of them,
> we'll fix it. If you just catch the exception, then maybe we find out,
> maybe we don't, and the bug is more likely to stay there. Also some
> applications, Excel being one example, feel like the worst thing we can
> ever do is to corrupt the user's data. Crashing is bad, but not the worst
> thing we can possibly do. So if Excel gets off in the weeds, it would
> rather fall over than corrupt your data.
>
>
And this is quite reasonable error behavior. So is the opposite, like I've
implemented on several applications, which is to abort the executing task
(*NO* need for a separate thread or process like it has been said in some
of the related posts), give the user some information and let him continue
using the application.
There isn't one correct *application* behavior because it depends on the
application.
Just to consider some opposing examples, Excel is basically about data
management so there is a big chance that an application bug would corrupt
the data. Maple OTOH, although similarly about "numbers", is about
algebraic computations, so is a lot more likely that a bug would simply
produce the wrong result. A Maple user would very much like to keep Maple
going so he can just workaround the bug by twiking the computations.


I did once have the X Window library do that to me (call exit()), and it
> was seriously annoying. So what you want is for the developer to decide
> what happens, which is what SafeInt does.
>

Exactly. It is the application (and not just any part of it) who must
decide how to respond to errors (even programming errors). Never the
library.




--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b6242b66d619104cf8565f4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Nov 27, 2=
012 at 11:50 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:dvd_leblanc@yahoo=
..com" target=3D"_blank">dvd_leblanc@yahoo.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">

<div class=3D"im"><br>On Tuesday, November 27, 2012 9:43:28 AM UTC-8, Ferna=
ndo Cacciola wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left=
-width:1px;border-left-style:solid">

<div><div class=3D"gmail_quote"><div><br>I&#39;m tempted to respond, but I =
think this thread is not the correct place. (and I&#39;m not sure where wou=
ld be)<br><br>Anyway, let me just rephrase that: IMO, the *end user* never =
ever wants you the programmer to structure the program in such a way that t=
he *entire application* must abort as opposed to the current &quot;task&quo=
t; (task from the end user POV )<br>



<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1p=
x;border-left-style:solid"><span><font color=3D"#888888">
</font></span></blockquote></div></div></blockquote></div><div>Somewhat off=
-topic, and very much platform-centric, but actually we do want that under=
=A0a number of conditions. On Windows, if the app aborts unexpectedly, and =
you have opted in to the=A0crash reporting feature, we then get a bug with =
a stack trace and possibly a dump. If we see many of them, we&#39;ll fix it=
.. If you just catch the exception, then maybe we find out, maybe we don&#39=
;t, and the bug is more likely to stay there. Also some applications, Excel=
 being one example, feel like the worst thing we can ever do is to corrupt =
the user&#39;s data. Crashing is bad, but not the worst thing we can possib=
ly do. So if Excel gets off in the weeds, it would rather fall over than co=
rrupt your data.</div>

<div>=A0</div></blockquote><div>And this is quite reasonable error behavior=
.. So is the opposite, like I&#39;ve implemented on several applications, wh=
ich is to abort the executing task (*NO* need for a separate thread or proc=
ess like it has been said in some of the related posts), give the user some=
 information and let him continue using the application.<br>

There isn&#39;t one correct *application* behavior because it depends on th=
e application. <br>Just to consider some opposing examples, Excel is basica=
lly about data management so there is a big chance that an application bug =
would corrupt the data. Maple OTOH, although similarly about &quot;numbers&=
quot;, is about algebraic computations, so is a lot more likely that a bug =
would simply produce the wrong result. A Maple user would very much like to=
 keep Maple going so he can just workaround the bug by twiking the computat=
ions.<br>

<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div>I did once have the X Win=
dow=A0library do that to me (call exit()), and it was seriously annoying. S=
o what you want is for the developer to decide what happens, which is=A0wha=
t SafeInt does.=A0</div>

</blockquote><div><br>Exactly. It is the application (and not just any part=
 of it) who must decide how to respond to errors (even programming errors).=
 Never the library.<br>=A0<br></div></div><br><br clear=3D"all"><br>-- <br>

Fernando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.s=
cisoft-consulting.com">http://www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6242b66d619104cf8565f4--

.

------=_Part_108_9487941.1354072940289
Content-Type: text/plain; charset=ISO-8859-1


On Tuesday, November 27, 2012 6:32:27 PM UTC-8, Fernando Cacciola wrote:
>
> Not on the interface.
> But the code uses _imul128 (or some such) for a certain operation over
> certain argument and given certain configuration options.
>
> So the implementation is using an operation on 128 integers.
>

That's a Microsoft-specific intrinsic (AFAIK). If it turns out to be
portable, I'd use it for other compilers, too. FWIW, it is not available on
32-bit Microsoft compilers.


> But that question was addressed to Robert. His library *sifnificantly*
> differs from yours in this regard:
>
>
> In Robert's library, safe<T> * safe<T> -> safe<2T>
>
> And I believe *that* is the correct choice (SafeInt<> does the opposite so
> I believe that's not the correct choice)
>
> Given that pattern, I ask what's the case when you already reached int64.
>

Ah - from the standpoint of keeping things from overflowing, I would tend
to agree. From the standpoint of being able to use it in production code
because I have not caused a perf problem, I disagree.

I would note that there could be a middle ground, though it may be tricky
to get to compile. You could say that for SafeInt of types smaller than
int, then the return would be SafeInt<int>

 >> And I would use a totally different *interface* but that's minor. What
matters IMO is the existence of these utilities, which I believe should not
be left hidden in the implementation.

Sure, complete agreement, and there are aspects of the existing interface I
am not completely happy with.



>
>>
> Else, we quickly get to all operations working on the largest possible
>> type, and perf would suffer badly.
>>
>>
> OK.
> Then that would be your argument for NOT automatically promoting to the
> next bigger type to avoid overflow.
>
> Right off the top of my head I disagree with your conclusion (I agree with
> the perf observation but not the conclusion you drew from that), but this
> is one thing that should be discussed as its own topic.
>
> OK.


>
> Maybe one of us is misreading the question.
>
> I read the question as: Should ( a + b ) and ( b + a) return the same type?
>
> I say yes.
>
> This gets into some level of implementation detail in terms of simplifying
assumptions. The class was significantly hard to develop, and evolved over
some years. The bulk of it was done in about 6 months. A simplifying
assumption is that some_int op SafeInt<other_int> always returns the
SafeInt<other_int>. This is true no matter what the order - we can do a +
safe_b or safe_b + a. All works and meets your requirement.

What is undefined is the case of SafeInt<T> op SafeInt<U>. I don't know
what type you want back, and compilers tend to just throw up their hands
and refuse to compile. You could have a large table of all the types, but
that's ugly. So I then ask you to make up your mind and do for example
(U)SafeInt<T> op SafeInt<U>.


> That approach will end up being infeasible due to perf issues.
>>
>>
> I would need you to elaborate on that.
>
> The worst thing you can ever ask this library to do is check 64-bit
multiplication. If you have the intrinsics, it is not too bad, but it is
still going to be expensive. I believe division gets significantly more
expensive as the types get larger, especially 64-bit division on a 32-bit
system. 64-bit addition is not quite as bad, and I don't have to do tricky
things in the code, but it will use more registers, and on 32-bit Intel
systems, we do not have many of those. As soon as you start using more
registers, you're going to cause some side-effects in terms of
optimizations.

So if you upcast a bunch of say 16-bit operations to 32-bit on a 32-bit
system, then that's not going to hurt you in general. But if you then have
two of those 32-bit values collide and want to go to 64-bit, now we have
problems. If you start looking through the code that really does the work,
the specializations for the smaller types tend to be very small and clean.
The specializations that deal with mixed-sign operations on 64-bit types
tend to be much more complex.

--




------=_Part_108_9487941.1354072940289
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Tuesday, November 27, 2012 6:32:27 PM UTC-8, Fernando Cacciola wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><div><div class=3D"gmail_quote"><div>Not on t=
he interface.<br>But the code uses _imul128 (or some such) for a certain op=
eration over certain argument and given certain configuration options.<br><=
br>So the implementation is using an operation on 128 integers.<br></div></=
div></div></blockquote><div>&nbsp;</div><div>That's a Microsoft-specific in=
trinsic (AFAIK). If it turns out to be portable, I'd use it for other compi=
lers, too. FWIW, it is not available on 32-bit Microsoft compilers.</div><d=
iv>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;"><div><div class=3D"gmail_quote"=
><div>

But that question was addressed to Robert. His library *sifnificantly* diff=
ers from yours in this regard:<br><br><br>In Robert's library, safe&lt;T&gt=
; * safe&lt;T&gt; -&gt; safe&lt;2T&gt;<br>

<br>And I believe *that* is the correct choice (SafeInt&lt;&gt; does the op=
posite so I believe that's not the correct choice)<br><br>Given that patter=
n, I ask what's the case when you already reached int64.<br></div></div></d=
iv></blockquote><div>&nbsp;</div><div>Ah - from the standpoint of keeping t=
hings from overflowing, I would tend to agree. From the standpoint of being=
 able to use it in production code because I have not caused a perf problem=
, I disagree.</div><div>&nbsp;</div><div>I would note that there could be a=
 middle ground, though it may be tricky to get to compile. You could say th=
at for SafeInt of types smaller than int, then the return would be SafeInt&=
lt;int&gt;</div><div>&nbsp;</div><div>&nbsp;&gt;&gt; And I would use a tota=
lly different *interface* but that's minor. What matters IMO is the existen=
ce of these utilities, which I believe should not be left hidden in the imp=
lementation.</div><div>&nbsp;</div><div>Sure, complete agreement, and there=
 are aspects of the existing interface I am not completely happy with.<br>

<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pad=
ding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1=
px; border-left-style: solid;"><div>&nbsp;</div></blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;"><div>Else, we quickly get to all operations working on the&n=
bsp;largest possible type, and perf would suffer badly.</div><div><div>&nbs=
p;</div></div></blockquote><div>OK.<br>Then that would be your argument for=
 NOT automatically promoting to the next bigger type to avoid overflow.<br>

<br>Right off the top of my head I disagree with your conclusion (I agree w=
ith the perf observation but not the conclusion you drew from that), but th=
is is one thing that should be discussed as its own topic.<br><br></div></d=
iv></div></blockquote><div>OK.</div><div>&nbsp;</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;"><div><div class=3D"gmail_quote"><div>&nbsp;</div><div>Maybe one of u=
s is misreading the question.<br><br>I read the question as: Should ( a + b=
 ) and ( b + a) return the same type?<br>

<br>I say yes.<br><br></div></div></div></blockquote><div>This gets into so=
me level of implementation detail in terms of simplifying assumptions. The =
class was significantly hard to develop, and evolved over some years. The b=
ulk of it was done in about 6 months. A simplifying assumption is that some=
_int op SafeInt&lt;other_int&gt; always returns the SafeInt&lt;other_int&gt=
;. This is true no matter what the order - we can do a + safe_b or safe_b&n=
bsp;+ a. All&nbsp;works and meets your requirement.</div><div>&nbsp;</div><=
div>What is undefined is the case of SafeInt&lt;T&gt; op SafeInt&lt;U&gt;. =
I don't know what type you want back,&nbsp;and compilers tend to just throw=
 up their hands and refuse to compile. You could have a large table of all =
the types, but that's ugly. So I then ask you to make up your mind and do f=
or example (U)SafeInt&lt;T&gt; op SafeInt&lt;U&gt;.</div><div>&nbsp;&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width=
: 1px; border-left-style: solid;"><div><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: =
1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-=
left-style: solid;"><div>That approach will end up being infeasible due to =
perf issues.</div><span><font color=3D"#888888"><div>

&nbsp;</div></font></span></blockquote><div>I would need you to elaborate o=
n that.<br><br></div></div></div></blockquote><div>The worst thing you can =
ever ask this library to do is check 64-bit multiplication. If you have the=
 intrinsics, it is not too bad, but it is still going to be expensive. I be=
lieve division gets significantly more expensive as the types get larger, e=
specially 64-bit division on a 32-bit system. 64-bit addition is not quite =
as bad, and I don't have to&nbsp;do tricky things in the code, but it will =
use more registers, and on 32-bit Intel systems, we do not have many of tho=
se. As soon as you start using more registers, you're going to cause some s=
ide-effects&nbsp;in terms of optimizations.</div><div>&nbsp;</div><div>So i=
f you upcast a bunch of say 16-bit operations to 32-bit on a 32-bit system,=
 then that's not going to hurt you in general. But if you then have two of =
those&nbsp;32-bit values collide and want to go to 64-bit, now we have prob=
lems.&nbsp;If you start looking through the code that really does the work,=
 the specializations for the smaller types tend to be very small and clean.=
 The specializations that deal with mixed-sign&nbsp;operations on 64-bit ty=
pes tend to be much more complex.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_108_9487941.1354072940289--

.

------=_Part_1131_28223310.1354073510043
Content-Type: text/plain; charset=ISO-8859-1


On Tuesday, November 27, 2012 10:05:27 AM UTC-8, viboes wrote:
>
>
> I don't know if your SafeInt/safe<T> prevents from assignments from
> signed values to unsigned types, but this could also be useful.
>
No, it does not prevent it, but it does check that the assignment is within
range. It does the same thing on a cast, which can result in
some interesting bugs, for example:

SafeInt<unsigned int> x;

// code happens

if ((int)x < 0)
  complain();

Never calls complain, it just throws.

--




------=_Part_1131_28223310.1354073510043
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Tuesday, November 27, 2012 10:05:27 AM UTC-8, viboes wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: =
1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-=
left-style: solid;"><br>I don't know if your SafeInt/safe&lt;T&gt; prevents=
 from assignments from=20
<br>signed values to unsigned types, but this could also be useful.
<br>
</blockquote><div>No, it does not prevent it, but it does check that the as=
signment is within range. It does the same thing on a cast, which can resul=
t in some&nbsp;interesting bugs, for example:</div><div>&nbsp;</div><div>Sa=
feInt&lt;unsigned int&gt; x;</div><div>&nbsp;</div><div>// code happens</di=
v><div>&nbsp;</div><div>if ((int)x&nbsp;&lt; 0)</div><div>&nbsp; complain()=
;</div><div>&nbsp;</div><div>Never calls complain, it just throws.&nbsp;</d=
iv>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1131_28223310.1354073510043--

.

------=_Part_1511_28180838.1354086024415
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, November 27, 2012 5:02:37 PM UTC-8, dvd_l...@yahoo.com wrote:
>
> If you are going to derive something from my work, please follow the
> license. It doesn't ask much, just that you keep attribution and the
> license. If you are going to completely rewrite something based on my work,
> then you may not need a license (I Am Not A Lawyer, one should be asked),
> but attribution would be nice.
>

I'm sure that a simple inspection of my code will convince anyone that it's
not a derivation.  The documentation has an Acknowledgements page in which
you and your work are prominently mentioned. I was really looking for
something like safe_range<min, max>.  I new about your library and had used
it before to good effect. When I looked into your code I found it hard to
follow and felt that a TMP approach would result in a more regular and
smaller code base.  Also I had trouble actually finding the package and
when I did, I couldn't find the documentation or tests. I knew tests were
around since I had remembered seeing them.  Also it seemed there were a
couple of versions - some portable to gcc and others only for vc.  I also
felt the notion of "safe" type could be generalized to all types supported
by std::limits.  For all these reasons I felt it need a fresh cut.  There
is not question I was inspired by your library - and I still am.  One could
well consider safe<T> a successor to SafeInt but I don't think derivation
is a fair characterization.  The code is available for inspection by anyone
who is actually interested in this point.

Robert Ramey


--




------=_Part_1511_28180838.1354086024415
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, November 27, 2012 5:02:37 PM UTC-8, dvd_l...@yahoo.com =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>If you are going to=
 derive something from my work, please follow the license. It doesn't ask m=
uch, just that you keep attribution and the license. If you are going to co=
mpletely rewrite something based on my work, then you may not need a licens=
e (I Am Not A Lawyer, one should be asked), but attribution would be nice.<=
/div></blockquote><div><br>I'm sure that a simple inspection of my code wil=
l convince anyone that it's not a derivation.&nbsp; The documentation has a=
n Acknowledgements page in which you and your work are prominently mentione=
d. I was really looking for something like safe_range&lt;min, max&gt;.&nbsp=
; I new about your library and had used it before to good effect. When I lo=
oked into your code I found it hard to follow and felt that a TMP approach =
would result in a more regular and smaller code base.&nbsp; Also I had trou=
ble actually finding the package and when I did, I couldn't find the docume=
ntation or tests. I knew tests were around since I had remembered seeing th=
em.&nbsp; Also it seemed there were a couple of versions - some portable to=
 gcc and others only for vc.&nbsp; I also felt the notion of "safe" type co=
uld be generalized to all types supported by std::limits.&nbsp; For all the=
se reasons I felt it need a fresh cut.&nbsp; There is not question I was in=
spired by your library - and I still am.&nbsp; One could well consider safe=
&lt;T&gt; a successor to SafeInt but I don't think derivation is a fair cha=
racterization.&nbsp; The code is available for inspection by anyone who is =
actually interested in this point.<br><br>Robert Ramey<br>&nbsp;<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1511_28180838.1354086024415--

.

------=_Part_1606_14082828.1354088254464
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, November 27, 2012 7:22:20 PM UTC-8, dvd_l...@yahoo.com wrote:
>
>
> On Tuesday, November 27, 2012 6:32:27 PM UTC-8, Fernando Cacciola wrote:
>
>
>> But that question was addressed to Robert. His library *sifnificantly*
>> differs from yours in this regard:
>>
>>
>> In Robert's library, safe<T> * safe<T> -> safe<2T>
>>
>> And I believe *that* is the correct choice (SafeInt<> does the opposite
>> so I believe that's not the correct choice)
>>
>> Given that pattern, I ask what's the case when you already reached int64.
>>
>
> Ah - from the standpoint of keeping things from overflowing, I would tend
> to agree. From the standpoint of being able to use it in production code
> because I have not caused a perf problem, I disagree.
>

I'm not convinced that promoting the types to 64 bits is more expensive
timewise than the alternatives. I'd have to see some real data on that.


> I would note that there could be a middle ground, though it may be tricky
> to get to compile. You could say that for SafeInt of types smaller than
> int, then the return would be SafeInt<int>
>

This is very interesting.  When I started on this, I started with
"save_range<min, max>" from which safe<int> is derived.  This left open the
possibility of using safe_range<0, 4> * safe_range<0,8>  to return a
safe_range<0, 12> which was very cool to me.  But the TMP got just to
complex and I scaled back my so that safe_range<0,4> is implemented as a
safe<unsigned char> etc.

What is undefined is the case of SafeInt<T> op SafeInt<U>. I don't know
> what type you want back, and compilers tend to just throw up their hands
> and refuse to compile. You could have a large table of all the types, but
> that's ugly. So I then ask you to make up your mind and do for example
> (U)SafeInt<T> op SafeInt<U>.
>

FWIW safe<int32> * safe<int16> will return safe<int64.  safe<int8> +
safe<int16> will return safe<int32> ...


Robert Ramey

--




------=_Part_1606_14082828.1354088254464
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, November 27, 2012 7:22:20 PM UTC-8, dvd_l...@yahoo.com =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>On Tuesday, November=
 27, 2012 6:32:27 PM UTC-8, Fernando Cacciola wrote:<div>&nbsp;</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:=
1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-st=
yle:solid"><div><div class=3D"gmail_quote"><div>

But that question was addressed to Robert. His library *sifnificantly* diff=
ers from yours in this regard:<br><br><br>In Robert's library, safe&lt;T&gt=
; * safe&lt;T&gt; -&gt; safe&lt;2T&gt;<br>

<br>And I believe *that* is the correct choice (SafeInt&lt;&gt; does the op=
posite so I believe that's not the correct choice)<br><br>Given that patter=
n, I ask what's the case when you already reached int64.<br></div></div></d=
iv></blockquote><div>&nbsp;</div><div>Ah - from the standpoint of keeping t=
hings from overflowing, I would tend to agree. From the standpoint of being=
 able to use it in production code because I have not caused a perf problem=
, I disagree.</div></blockquote><div><br>I'm not convinced that promoting t=
he types to 64 bits is more expensive timewise than the alternatives. I'd h=
ave to see some real data on that.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div>&nbsp;</div><div>I would note that there could be a =
middle ground, though it may be tricky to get to compile. You could say tha=
t for SafeInt of types smaller than int, then the return would be SafeInt&l=
t;int&gt;</div></blockquote><div><br>This is very interesting.&nbsp; When I=
 started on this, I started with "save_range&lt;min, max&gt;" from which sa=
fe&lt;int&gt; is derived.&nbsp; This left open the possibility of using saf=
e_range&lt;0, 4&gt; * safe_range&lt;0,8&gt;&nbsp; to return a safe_range&lt=
;0, 12&gt; which was very cool to me.&nbsp; But the TMP got just to complex=
 and I scaled back my so that safe_range&lt;0,4&gt; is implemented as a saf=
e&lt;unsigned char&gt; etc.<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div>What is undefined is the case of SafeInt&lt;T&gt; op SafeIn=
t&lt;U&gt;. I don't know what type you want back,&nbsp;and compilers tend t=
o just throw up their hands and refuse to compile. You could have a large t=
able of all the types, but that's ugly. So I then ask you to make up your m=
ind and do for example (U)SafeInt&lt;T&gt; op SafeInt&lt;U&gt;.</div></bloc=
kquote><div><br>FWIW safe&lt;int32&gt; * safe&lt;int16&gt; will return safe=
&lt;int64.&nbsp; safe&lt;int8&gt; + safe&lt;int16&gt; will return safe&lt;i=
nt32&gt; ...<br><br><br>Robert Ramey<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1606_14082828.1354088254464--

.

--047d7b621ede3d34c704cf8d09c0
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 28, 2012 at 12:22 AM, <dvd_leblanc@yahoo.com> wrote:

>
> On Tuesday, November 27, 2012 6:32:27 PM UTC-8, Fernando Cacciola wrote:
>>
>> Not on the interface.
>> But the code uses _imul128 (or some such) for a certain operation over
>> certain argument and given certain configuration options.
>>
>> So the implementation is using an operation on 128 integers.
>>
>
> That's a Microsoft-specific intrinsic (AFAIK). If it turns out to be
> portable, I'd use it for other compilers, too. FWIW, it is not available on
> 32-bit Microsoft compilers.
>
>
>>  But that question was addressed to Robert. His library *sifnificantly*
>> differs from yours in this regard:
>>
>>
>> In Robert's library, safe<T> * safe<T> -> safe<2T>
>>
>> And I believe *that* is the correct choice (SafeInt<> does the opposite
>> so I believe that's not the correct choice)
>>
>> Given that pattern, I ask what's the case when you already reached int64.
>>
>
> Ah - from the standpoint of keeping things from overflowing, I would tend
> to agree. From the standpoint of being able to use it in production code
> because I have not caused a perf problem, I disagree.
>
> I would note that there could be a middle ground, though it may be tricky
> to get to compile. You could say that for SafeInt of types smaller than
> int, then the return would be SafeInt<int>
>
>
OK.

I agree that there are two separate goals. One is to avoid overflow by
promoting to the next integer This would reach bigint in the end. The other
is to turn overflow into well defined and *useful* behavior, but without
any need to avoid it, just to deal with it.

From your use cases I can see that SafeInt is aimed at the later. The uses
I have in mind are closer to the former.

So, IMO a proposal should contemplate both, and possibly, provide utilities
to both problems.


>  >> And I would use a totally different *interface* but that's minor. What
> matters IMO is the existence of these utilities, which I believe should not
> be left hidden in the implementation.
>
> Sure, complete agreement, and there are aspects of the existing interface
> I am not completely happy with.
>
>
>
>>
>>>
>> Else, we quickly get to all operations working on the largest possible
>>> type, and perf would suffer badly.
>>>
>>>
>> OK.
>> Then that would be your argument for NOT automatically promoting to the
>> next bigger type to avoid overflow.
>>
>> Right off the top of my head I disagree with your conclusion (I agree
>> with the perf observation but not the conclusion you drew from that), but
>> this is one thing that should be discussed as its own topic.
>>
>> OK.
>
>
>>
>> Maybe one of us is misreading the question.
>>
>> I read the question as: Should ( a + b ) and ( b + a) return the same
>> type?
>>
>> I say yes.
>>
>> This gets into some level of implementation detail in terms of
> simplifying assumptions. The class was significantly hard to develop, and
> evolved over some years. The bulk of it was done in about 6 months. A
> simplifying assumption is that some_int op SafeInt<other_int> always
> returns the SafeInt<other_int>. This is true no matter what the order - we
> can do a + safe_b or safe_b + a. All works and meets your requirement.
>
> What is undefined is the case of SafeInt<T> op SafeInt<U>. I don't know
> what type you want back, and compilers tend to just throw up their hands
> and refuse to compile. You could have a large table of all the types, but
> that's ugly. So I then ask you to make up your mind and do for example
> (U)SafeInt<T> op SafeInt<U>.
>
>

Integer types are ranked based on their ranges. That's used in integer
promotion. IMO, it's perfectly valid and I would say simple to define
similar promotion rules for SafeInt<T> op SafeInt<U> based on the operation.


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b621ede3d34c704cf8d09c0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, Nov 28, 2012 =
at 12:22 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:dvd_leblanc@yahoo.com=
" target=3D"_blank">dvd_leblanc@yahoo.com</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">

<div class=3D"im"><br>On Tuesday, November 27, 2012 6:32:27 PM UTC-8, Ferna=
ndo Cacciola wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left=
-width:1px;border-left-style:solid">

<div><div class=3D"gmail_quote"><div>Not on the interface.<br>But the code =
uses _imul128 (or some such) for a certain operation over certain argument =
and given certain configuration options.<br><br>So the implementation is us=
ing an operation on 128 integers.<br>

</div></div></div></blockquote><div>=A0</div></div><div>That&#39;s a Micros=
oft-specific intrinsic (AFAIK). If it turns out to be portable, I&#39;d use=
 it for other compilers, too. FWIW, it is not available on 32-bit Microsoft=
 compilers.</div>

<div class=3D"im"><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div><div class=3D"gmail_q=
uote">

<div>

But that question was addressed to Robert. His library *sifnificantly* diff=
ers from yours in this regard:<br><br><br>In Robert&#39;s library, safe&lt;=
T&gt; * safe&lt;T&gt; -&gt; safe&lt;2T&gt;<br>

<br>And I believe *that* is the correct choice (SafeInt&lt;&gt; does the op=
posite so I believe that&#39;s not the correct choice)<br><br>Given that pa=
ttern, I ask what&#39;s the case when you already reached int64.<br></div>

</div></div></blockquote><div>=A0</div></div><div>Ah - from the standpoint =
of keeping things from overflowing, I would tend to agree. From the standpo=
int of being able to use it in production code because I have not caused a =
perf problem, I disagree.</div>

<div>=A0</div><div>I would note that there could be a middle ground, though=
 it may be tricky to get to compile. You could say that for SafeInt of type=
s smaller than int, then the return would be SafeInt&lt;int&gt;</div><div c=
lass=3D"im">

<div>=A0</div></div></blockquote><div>OK.<br><br>I agree that there are two=
 separate goals. One is to avoid overflow by promoting to the next integer =
This would reach bigint in the end. The other is to turn overflow into well=
 defined and *useful* behavior, but without any need to avoid it, just to d=
eal with it.<br>

<br>From your use cases I can see that SafeInt is aimed at the later. The u=
ses I have in mind are closer to the former.<br><br>So, IMO a proposal shou=
ld contemplate both, and possibly, provide utilities to both problems.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"><div>=A0&gt;&=
gt; And I would use a totally different *interface* but that&#39;s minor. W=
hat matters IMO is the existence of these utilities, which I believe should=
 not be left hidden in the implementation.</div>

<div>=A0</div></div><div>Sure, complete agreement, and there are aspects of=
 the existing interface I am not completely happy with.<br>

<br>=A0</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204)=
;border-left-width:1px;border-left-style:solid"><div><div class=3D"gmail_qu=
ote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div>=A0</div></blockquote><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb=
(204,204,204);border-left-width:1px;border-left-style:solid">

<div>Else, we quickly get to all operations working on the=A0largest possib=
le type, and perf would suffer badly.</div><div><div>=A0</div></div></block=
quote><div>OK.<br>Then that would be your argument for NOT automatically pr=
omoting to the next bigger type to avoid overflow.<br>



<br>Right off the top of my head I disagree with your conclusion (I agree w=
ith the perf observation but not the conclusion you drew from that), but th=
is is one thing that should be discussed as its own topic.<br><br></div>

</div></div></blockquote></div><div>OK.</div><div class=3D"im"><div>=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddi=
ng-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border=
-left-style:solid">

<div><div class=3D"gmail_quote"><div>=A0</div><div>Maybe one of us is misre=
ading the question.<br><br>I read the question as: Should ( a + b ) and ( b=
 + a) return the same type?<br>

<br>I say yes.<br><br></div></div></div></blockquote></div><div>This gets i=
nto some level of implementation detail in terms of simplifying assumptions=
.. The class was significantly hard to develop, and evolved over some years.=
 The bulk of it was done in about 6 months. A simplifying assumption is tha=
t some_int op SafeInt&lt;other_int&gt; always returns the SafeInt&lt;other_=
int&gt;. This is true no matter what the order - we can do a + safe_b or sa=
fe_b=A0+ a. All=A0works and meets your requirement.</div>

<div>=A0</div><div>What is undefined is the case of SafeInt&lt;T&gt; op Saf=
eInt&lt;U&gt;. I don&#39;t know what type you want back,=A0and compilers te=
nd to just throw up their hands and refuse to compile. You could have a lar=
ge table of all the types, but that&#39;s ugly. So I then ask you to make u=
p your mind and do for example (U)SafeInt&lt;T&gt; op SafeInt&lt;U&gt;.</di=
v>

<div class=3D"im"><div>=A0=A0</div></div></blockquote><div><br>Integer type=
s are ranked based on their ranges. That&#39;s used in integer promotion. I=
MO, it&#39;s perfectly valid and I would say simple to define similar promo=
tion rules for SafeInt&lt;T&gt; op SafeInt&lt;U&gt; based on the operation.=
<br>

<br></div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder=
<br><a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consul=
ting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b621ede3d34c704cf8d09c0--

.

--047d7b621df824dabd04cf8d1a17
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 28, 2012 at 4:37 AM, <robertmacleranramey@gmail.com> wrote:

>
> This is very interesting.  When I started on this, I started with
> "save_range<min, max>" from which safe<int> is derived.  This left open the
> possibility of using safe_range<0, 4> * safe_range<0,8>  to return a
> safe_range<0, 12> which was very cool to me.  But the TMP got just to
> complex and I scaled back my so that safe_range<0,4> is implemented as a
> safe<unsigned char> etc.
>
>
OTOH, in our context: a std proposal, we can just leave that to the
implementations (knowing that it could be complex, but *can* be done).
There are far more difficult things in the new language definition, so much
that haven't even been implemented yet.



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b621df824dabd04cf8d1a17
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, Nov 28, 2012 =
at 4:37 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:robertmacleranramey@gm=
ail.com" target=3D"_blank">robertmacleranramey@gmail.com</a>&gt;</span> wro=
te:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
></div>

</blockquote><div><br>This is very interesting.=A0 When I started on this, =
I started with &quot;save_range&lt;min, max&gt;&quot; from which safe&lt;in=
t&gt; is derived.=A0 This left open the possibility of using safe_range&lt;=
0, 4&gt; * safe_range&lt;0,8&gt;=A0 to return a safe_range&lt;0, 12&gt; whi=
ch was very cool to me.=A0 But the TMP got just to complex and I scaled bac=
k my so that safe_range&lt;0,4&gt; is implemented as a safe&lt;unsigned cha=
r&gt; etc.<br>

<br></div></blockquote><div><br>OTOH, in our context: a std proposal, we ca=
n just leave that to the implementations (knowing that it could be complex,=
 but *can* be done). There are far more difficult things in the new languag=
e definition, so much that haven&#39;t even been implemented yet.<br>

<br></div></div><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSoft C=
onsulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">http://=
www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b621df824dabd04cf8d1a17--

.

--e89a8f923f3a92804b04cf8e1610
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 28, 2012 at 12:01 AM, <dvd_leblanc@yahoo.com> wrote:

>
> On Tuesday, November 27, 2012 6:19:32 PM UTC-8, Fernando Cacciola wrote:
>>
>>
>>
>> I was referring to the implementation.
>> In the code (I did actually look), you do perform "the primitive
>> operation in a type that has twice the precision" of the operands.
>>
>> Oh - OK. This is not always true, though. Addition can be checked without
> larger types, and sometimes I just leverage normal operator casting
> behavior - char op char does not go to short, but instead int. For
> multiplication, this is the case for 32-bit types.
>
>>
>>
>>>
>>>
>> To some extent, I agree. Though there is support for this in SafeInt -
>>> there are templatized functions that will answer the general question of
>>> whether an addition (for example) between two arbitrary types is going to
>>> have a numerically valid result.
>>>
>>
>> I know. I saw them in the code.
>> And I'm saying that such functions (or whatever, it doesn't really matter
>> what it is exactly, to the effect of my point) are a bottom layer of
>> SafeInt but they would be equally useful as a bottom layer for several
>> other integer related utility classes.
>> Then, I propose to standarize *them* as well.
>>
> Thanks, then yes, we agree on that. However, you would need both throwing
> and non-throwing semantics, as you see in the code. The throwing semantics
> can sometimes have a cleaner failure path.
>

IIUC, this is because you have failure policies.
If, OTOH, the library just consistently throw as the sole overflow handling
mechanism, you won't need both.

I would (and probably will) argue that, a *standard library utility* should
just consistently throw. Or else, something at a wider lever, across
libraries, should be proposed.


>
>
>>
>>
>>> We tried this, and it did not go well. Great idea, and we even
>>> implemented it and put it into a fair bit of code, but we've since
>>> abandoned the approach and removed uses of it. The best solution we've
>>> found so far is the templatized, non-throwing functions.
>>>
>>
>> Fair enough.
>> OTOH, I believe it is reasonable to ask for a rationale on why it did not
>> work, and to allow us to have some discussion about it, which would not
>> ignore your experience but simply try to consider different contexts which
>> might have not been taken into account when you first consider it.
>>
>> For example, you said "Turned out to be unusable, since a simple check
>> like if (SafeCheckedInt<int>(x) < 0) might throw"
>>
>>
> Why would that throw? I don't get it
>>
>
> If the checked int had overflowed
>

OK, so you actually meant to write:

SafeCheckedInt<int> x ;
....
if ( x < 0 )

because in your example, the checked int is a temporary constructed in the
expression so I know it hadn't overflowed.



> , then we cannot answer the question of whether it is < 0, because it is
> undefined.
>

Right, we can't.



> Only thing we can do is throw at that point.
>

Correct


> This tends to cause serious problems when trying to use it in existing
> code.
>
>
How so?

The very purpose of this utility is to make sure the user never ever deals
with "an apparent" value that is not really so because it's actually
undefined.
That should cover all cases where the value is being accessed, which would
include comparisons, not just assignment and conversions.

UNLESS, it is decided by design that you *can* compare overflowed (that is
undefined) values.  This is valid design, and there are conceptually
similar libraries that follow it.
This, however, can *only* be implemented if the overflowed state is stored
inside SafeInt (as opposed to throw right up front when the overflow is
detected)


I'm certainly willing to discuss the idea - one possibility is that our
> implementation or design was bad.
>

IME, most thoughtful implementations and designs are not bad, but can be
improved as new use cases or updated requirements are discovered.



> Some other approach might work. We originally liked the idea because a
> float can tell us if it has become an undefined value, seemed like this
> concept should transfer. Part of it was confusion because a SafeInt can
> never become invalid, and a comparison operation can never throw.
>

It was specifically designed so it never becomes invalid and comparisons
never throw.

A float can be "invalid" (NAN), and NANs *can* be compared for example
without a trap (of course I'm referring to non signaling NANs, which are
the most common)



> So introducing something that acts somewhat the same, but throws in places
> the other cannot was a mess.
>
>

If SafeInt is compared to builtin int, then it indeed can throw in places
the builtin won't. But that is *precisely* the idea of SafeInt.

>


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--e89a8f923f3a92804b04cf8e1610
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, Nov 28, 2012 =
at 12:01 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:dvd_leblanc@yahoo.com=
" target=3D"_blank">dvd_leblanc@yahoo.com</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">

<div class=3D"im"><br>On Tuesday, November 27, 2012 6:19:32 PM UTC-8, Ferna=
ndo Cacciola wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left=
-width:1px;border-left-style:solid">

<div><br><br>I was referring to the implementation.<br>

In the code (I did actually look), you do perform &quot;the primitive opera=
tion in a type that has twice the precision&quot; of the operands.<br><br><=
/div></blockquote></div><div>Oh - OK. This is not=A0always true, though. Ad=
dition can be checked without larger types, and sometimes I just leverage n=
ormal operator casting behavior - char op char does not go to short, but in=
stead int. For multiplication, this is the case for 32-bit types.=A0</div>

<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-=
width:1px;border-left-style:solid"><div>=A0<br><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-=
left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-le=
ft-style:solid">



<div>=A0</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bor=
der-left-width:1px;border-left-style:solid"><div>To some extent, I agree. T=
hough there is support for this in SafeInt - there are templatized function=
s that will answer the general question of whether an addition (for example=
) between two arbitrary types is going to have a numerically valid result.<=
/div>



<div><div></div></div></blockquote><div><br>I know. I saw them in the code.=
<br>And I&#39;m saying that such functions (or whatever, it doesn&#39;t rea=
lly matter what it is exactly, to the effect of my point) are a bottom laye=
r of SafeInt but they would be equally useful as a bottom layer for several=
 other integer related utility classes.<br>



Then, I propose to standarize *them* as well.<br></div></div></div></blockq=
uote></div><div>Thanks, then yes, we agree on that. However, you would need=
 both throwing and non-throwing semantics, as you see in the code. The thro=
wing semantics can sometimes have a=A0cleaner failure path.</div>

</blockquote><div><br>IIUC, this is because you have failure policies.<br>I=
f, OTOH, the library just consistently throw as the sole overflow handling =
mechanism, you won&#39;t need both.<br><br>I would (and probably will) argu=
e that, a *standard library utility* should just consistently throw. Or els=
e, something at a wider lever, across libraries, should be proposed.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"><div>=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid">

<div><div class=3D"gmail_quote"><div>=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:r=
gb(204,204,204);border-left-width:1px;border-left-style:solid"><div>We trie=
d this, and it did not go well. Great idea,=A0and we even implemented it an=
d put it into a fair bit of code, but we&#39;ve since abandoned the approac=
h and=A0removed uses=A0of it. The best solution we&#39;ve found so far is t=
he templatized, non-throwing functions.=A0</div>



</blockquote><div><br>Fair enough. <br>OTOH, I believe it is reasonable to =
ask for a rationale on why it did not work, and to allow us to have some di=
scussion about it, which would not ignore your experience but simply try to=
 consider different contexts which might have not been taken into account w=
hen you first consider it.<br>



<br>For example, you said &quot;Turned out to be unusable, since a simple c=
heck like if (SafeCheckedInt&lt;int&gt;(x) &lt; 0) might throw&quot;<br>=A0=
</div></div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204)=
;border-left-width:1px;border-left-style:solid">

<div><div class=3D"gmail_quote"><div>Why would that throw? I don&#39;t get =
it<br></div></div></div></blockquote><div>=A0</div></div><div>If=A0the chec=
ked int had overflowed</div></blockquote><div><br>OK, so you actually meant=
 to write:<br>

<br>SafeCheckedInt&lt;int&gt; x ;<br>...<br>if ( x &lt; 0 )<br><br>because =
in your example, the checked int is a temporary constructed in the expressi=
on so I know it hadn&#39;t overflowed.<br><br>=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">

<div>, then we cannot answer the question of whether it is=A0&lt; 0, becaus=
e it is undefined. </div></blockquote><div><br>Right, we can&#39;t. <br><br=
>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">

<div>Only thing we can do is throw at that point. </div></blockquote><div><=
br>Correct<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>This tends to ca=
use serious problems when trying to use it in existing code.</div>

<div>=A0</div></blockquote><div>How so?<br><br>The very purpose of this uti=
lity is to make sure the user never ever deals with &quot;an apparent&quot;=
 value that is not really so because it&#39;s actually undefined.<br>That s=
hould cover all cases where the value is being accessed, which would includ=
e comparisons, not just assignment and conversions.<br>

<br>UNLESS, it is decided by design that you *can* compare overflowed (that=
 is undefined) values.=A0 This is valid design, and there are conceptually =
similar libraries that follow it.<br>This, however, can *only* be implement=
ed if the overflowed state is stored inside SafeInt (as opposed to throw ri=
ght up front when the overflow is detected)<br>

<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div>I&#39;m certainly willing=
 to discuss the idea - one possibility is that our implementation or design=
 was bad. </div>

</blockquote><div><br>IME, most thoughtful implementations and designs are =
not bad, but can be improved as new use cases or updated requirements are d=
iscovered. <br><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>Some other approach might work. We originally liked the idea because a=
 float can tell us if it has become an undefined value, seemed like this co=
ncept should transfer. Part of it was confusion because a SafeInt can never=
 become invalid, and a comparison operation can never throw. </div>

</blockquote><div><br>It was specifically designed so it never becomes inva=
lid and comparisons never throw.<br><br>A float can be &quot;invalid&quot; =
(NAN), and NANs *can* be compared for example without a trap (of course I&#=
39;m referring to non signaling NANs, which are the most common)<br>

<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div>So introducing something t=
hat acts somewhat the same, but throws in places the other cannot was a mes=
s.</div>

<div>=A0</div></blockquote><div class=3D"gmail_quote"><br>If SafeInt is com=
pared to builtin int, then it indeed can throw in places the builtin won&#3=
9;t. But that is *precisely* the idea of SafeInt. <br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></blockquote><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>


</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Fernando =
Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-co=
nsulting.com">http://www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f923f3a92804b04cf8e1610--

.

------=_Part_34_12724719.1354121088823
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, November 28, 2012 4:13:22 AM UTC-8, Fernando Cacciola wrote:
>
> On Wed, Nov 28, 2012 at 4:37 AM, <robertmac...@gmail.com <javascript:>>wrote:
>
>>
>> This is very interesting.  When I started on this, I started with
>> "save_range<min, max>" from which safe<int> is derived.  This left open the
>> possibility of using safe_range<0, 4> * safe_range<0,8>  to return a
>> safe_range<0, 12> which was very cool to me.  But the TMP got just to
>> complex and I scaled back my so that safe_range<0,4> is implemented as a
>> safe<unsigned char> etc.
>>
>>
> OTOH, in our context: a std proposal, we can just leave that to the
> implementations (knowing that it could be complex, but *can* be done).
> There are far more difficult things in the new language definition, so much
> that haven't even been implemented yet.
>

After I wrote this post I went back the check the code.  What I said above
is not correct.  The safe<T> library functions like the following:

a) safe<int<number of bits>> is just a thin wrapper around
safe_int_range<min int<number_of bits, max int<number of bits>.

b) so if one makes

safe_unsigned_range<0, 3> x;    // two bit integer
safe_unsigned_range<0, 15> y;  // four bit integer

x + y will be of type safe_unsigned_int<0, 63> // 7 bit integer
x + y + z will be of type safe_unsigned_int<0, 1023> // 10 bit integer

etc for other types (signed) and sizes.

This has the potential to speed up calculations on some machines
considerably.

I had toyed with implementing a compile time range arithmetic so that
rather than
using the nearest integer size one would use the actual ranges themselves
so htat
safe_int_range<m, n> + safe_int_range<p, q> would result in type
safe_int<m+p, n+q>.
This I could to for addition, but getting to into multiplication and
division got
complicated too fast.  So I settled on the above as an expedient compromise.

Robert Ramey

--




------=_Part_34_12724719.1354121088823
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, November 28, 2012 4:13:22 AM UTC-8, Fernando Cacciola=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div class=3D"gmai=
l_quote">On Wed, Nov 28, 2012 at 4:37 AM,  <span dir=3D"ltr">&lt;<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"SjUrXOFhn7MJ">robe=
rtmac...@gmail.com</a><wbr>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
></div>

</blockquote><div><br>This is very interesting.&nbsp; When I started on thi=
s, I started with "save_range&lt;min, max&gt;" from which safe&lt;int&gt; i=
s derived.&nbsp; This left open the possibility of using safe_range&lt;0, 4=
&gt; * safe_range&lt;0,8&gt;&nbsp; to return a safe_range&lt;0, 12&gt; whic=
h was very cool to me.&nbsp; But the TMP got just to complex and I scaled b=
ack my so that safe_range&lt;0,4&gt; is implemented as a safe&lt;unsigned c=
har&gt; etc.<br>

<br></div></blockquote><div><br>OTOH, in our context: a std proposal, we ca=
n just leave that to the implementations (knowing that it could be complex,=
 but *can* be done). There are far more difficult things in the new languag=
e definition, so much that haven't even been implemented yet.<br></div></di=
v></div></blockquote><div><br>After I wrote this post I went back the check=
 the code.&nbsp; What I said above is not correct.&nbsp; The safe&lt;T&gt; =
library functions like the following:<br><br>a) safe&lt;int&lt;number of bi=
ts&gt;&gt; is just a thin wrapper around safe_int_range&lt;min int&lt;numbe=
r_of bits, max int&lt;number of bits&gt;.<br><br>b) so if one makes <br><br=
>safe_unsigned_range&lt;0, 3&gt; x;&nbsp;&nbsp;&nbsp; // two bit integer<br=
>safe_unsigned_range&lt;0, 15&gt; y;&nbsp; // four bit integer<br><br>x + y=
 will be of type safe_unsigned_int&lt;0, 63&gt; // 7 bit integer<br>x + y +=
 z will be of type safe_unsigned_int&lt;0, 1023&gt; // 10 bit integer<br><b=
r>etc for other types (signed) and sizes.<br><br>This has the potential to =
speed up calculations on some machines considerably.<br><br>I had toyed wit=
h implementing a compile time range arithmetic so that rather than<br>using=
 the nearest integer size one would use the actual ranges themselves so hta=
t<br>safe_int_range&lt;m, n&gt; + safe_int_range&lt;p, q&gt; would result i=
n type safe_int&lt;m+p, n+q&gt;.<br>This I could to for addition, but getti=
ng to into multiplication and division got<br>complicated too fast.&nbsp; S=
o I settled on the above as an expedient compromise.<br><br>Robert Ramey<br=
><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_34_12724719.1354121088823--

.

This is a multi-part message in MIME format.
--------------040903030408020907010304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I use my own safeint extensively, and find it to be very useful in
protecting from various kinds of overflow.

There is (in my opinion) one major design flaw in safeint, namely the
operators like:

'operator int() const', which allow the safeint to be turned back into
an int, for function calls. I prefer having a member function 'x.raw()',
or new function 'checked_cast<int>(x)'. This does make code using
safeint much more verbose, but means you cannot accidentally invoke
unsafe behaviour, by turning back into non-safe types.

I feel if someone is going to the effort of using safeint, then they
should care both when values are turned into safeint, and turned back.
However, this goes get particularly annoying when doing things like
indexing vectors, where you must keep writing 'v[x.raw()]' all the time.

Chris


On 08/11/12 02:59, Ben Craig wrote:
> SafeInt information can be found here <http://safeint.codeplex.com/>.
> Basically, it is an open source library authored by security expert
> David LeBlanc of Microsoft.  It is basically a "drop-in" replacement
> for integer types, and will throw an exception whenever integer
> overflows occur.  I believe that getting this added to the standard
> would be a boon to C++ and secure code.  It should be a relatively low
> effort addition considering the "proof-of-concept" is already widely
> used within Microsoft.
> --
>
>
>

--




--------------040903030408020907010304
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I use my own safeint extensively, and
      find it to be very useful in protecting from various kinds of
      overflow.<br>
      <br>
      There is (in my opinion) one major design flaw in safeint, namely
      the operators like:<br>
      <br>
      'operator int() const', which allow the safeint to be turned back
      into an int, for function calls. I prefer having a member function
      'x.raw()', or new function 'checked_cast&lt;int&gt;(x)'. This does
      make code using safeint much more verbose, but means you cannot
      accidentally invoke unsafe behaviour, by turning back into
      non-safe types.<br>
      <br>
      I feel if someone is going to the effort of using safeint, then
      they should care both when values are turned into safeint, and
      turned back. However, this goes get particularly annoying when
      doing things like indexing vectors, where you must keep writing
      'v[x.raw()]' all the time.<br>
      <br>
      Chris<br>
      <br>
      <br>
      On 08/11/12 02:59, Ben Craig wrote:<br>
    </div>
    <blockquote
      cite="mid:604806bd-962c-4a49-a974-ddf34722867d@isocpp.org"
      type="cite">SafeInt information can be found <a
        moz-do-not-send="true" href="http://safeint.codeplex.com/">here</a>.&nbsp;
      Basically, it is an open source library authored by security
      expert David LeBlanc of Microsoft.&nbsp; It is basically a "drop-in"
      replacement for integer types, and will throw an exception
      whenever integer overflows occur.&nbsp; I believe that getting this
      added to the standard would be a boon to C++ and secure code.&nbsp; It
      should be a relatively low effort addition considering the
      "proof-of-concept" is already widely used within Microsoft.<br>
      -- <br>
      &nbsp;<br>
      &nbsp;<br>
      &nbsp;<br>
    </blockquote>
    <br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--------------040903030408020907010304--

.

------=_Part_23_18377105.1354135547286
Content-Type: text/plain; charset=ISO-8859-1


On Tuesday, November 27, 2012 11:37:34 PM UTC-8, robertmac...@gmail.com
wrote:
>
>
>
>>
>> Ah - from the standpoint of keeping things from overflowing, I would tend
>> to agree. From the standpoint of being able to use it in production code
>> because I have not caused a perf problem, I disagree.
>>
>
> I'm not convinced that promoting the types to 64 bits is more expensive
> timewise than the alternatives. I'd have to see some real data on that.
>
> OK, so looking at the case of multiplication on a 32-bit system, to do a
32-bit multiplication, we take 2 registers, and run imul, which then places
the result in one of the source registers. Pretty lean. Now go look at what
happens with a worst-case 64-bit multiplication - we pack our data into 4
registers (which is half of our general purpose registers), and then (at
least when doing this with Visual Studio - I expect other compilers will be
similar) enters a function which will call another 16 assembly
instructions, at least two of which (possibly 4 - (a + b) * (c + d
) expands to ac+ ad + bc + bd) are multiplications.

Without considering the side-effects of chewing up half the available
registers, we're looking at twice the multiplication instructions, and a
total of about 20 assembly instructions vs. three. Some of that's common
code, but for every multiplication we've doubled the number of instructions
at each point, which expands the size of the code, which hurts perf.

If we look at an addition, you have a similar issue where instead of 2
registers you now have four, and you will have 2 adds. If I wanted to be
careful about it, we could go count cycles per instruction and add them up,
but the raw instruction count is so much different that it is obvious what
the result will be.

Division will do the same thing, and you will find that a 64-bit division
is a very expensive thing to do. 32-bit division is not cheap, but 64-bit
is worse.

Expanding the size like this violates one of the constraints I had, which
was that you should be able to change a declaration from int to
SafeInt<int>, and not have a substantial perf loss.

If what you want to do is just lose data as little as possible, and perf
isn't a problem for you, then some sort of big int variable length integer
class would do the job.


>
>> I would note that there could be a middle ground, though it may be tricky
>> to get to compile. You could say that for SafeInt of types smaller than
>> int, then the return would be SafeInt<int>
>>
>
> This is very interesting.  When I started on this, I started with
> "save_range<min, max>" from which safe<int> is derived.  This left open the
> possibility of using safe_range<0, 4> * safe_range<0,8>  to return a
> safe_range<0, 12> which was very cool to me.  But the TMP got just to
> complex and I scaled back my so that safe_range<0,4> is implemented as a
> safe<unsigned char> etc.
>
>
This could be done, but you'd have to do a partial template specialization
over the entire class, and you'd end up with multiple versions of all the
members. While it is enticing from an academic standpoint, from a work
needed to implement standpoint, it is tough to justify. And in practice,
we're most often working with 32-bit instances, second most frequent case
is mixed 32 and 64-bit.


--




------=_Part_23_18377105.1354135547286
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Tuesday, November 27, 2012 11:37:34 PM UTC-8, robertmac...@gmail.com=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wid=
th: 1px; border-left-style: solid;"><br>&nbsp;<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div>Ah - from the standpoint of keeping things from overflowing, I would t=
end to agree. From the standpoint of being able to use it in production cod=
e because I have not caused a perf problem, I disagree.</div></blockquote><=
div><br>I'm not convinced that promoting the types to 64 bits is more expen=
sive timewise than the alternatives. I'd have to see some real data on that=
..<br><br></div></blockquote><div>OK, so looking at the&nbsp;case of multipl=
ication on a 32-bit system, to do a 32-bit multiplication, we take 2 regist=
ers, and run imul, which then places the result in one of the&nbsp;source r=
egisters. Pretty lean. Now go look at what happens with a worst-case 64-bit=
 multiplication - we pack our data into 4 registers (which is half of our g=
eneral purpose registers), and then (at least when doing this with Visual S=
tudio - I expect other compilers will be similar) enters a function which w=
ill call another 16 assembly instructions, at least two of which (possibly =
4 - (a + b) * (c + d )&nbsp;expands to ac+ ad + bc + bd)&nbsp;are multiplic=
ations.</div><div>&nbsp;</div><div>Without considering the side-effects of =
chewing up half the available registers, we're looking at twice the&nbsp;mu=
ltiplication instructions, and a total of about 20 assembly instructions vs=
..&nbsp;three. Some of that's common code, but for every multiplication we'v=
e doubled the number of instructions at each point, which expands the size =
of the code, which&nbsp;hurts perf. </div><div>&nbsp;</div><div>If we look =
at an addition, you have a similar issue where instead of 2 registers you n=
ow have four, and you will have 2 adds. If I wanted to be careful about it,=
 we could go count cycles per instruction and add them up, but the raw inst=
ruction count is so much different that it is obvious what the result will =
be.</div><div>&nbsp;</div><div>Division will do the same thing, and you wil=
l find that a 64-bit division is a very expensive thing to do. 32-bit divis=
ion is not cheap, but 64-bit is worse.</div><div>&nbsp;</div><div>Expanding=
 the size like this violates one of the constraints I had, which was that y=
ou should be able to change a declaration from int to SafeInt&lt;int&gt;, a=
nd not have a substantial perf loss.</div><div>&nbsp;</div><div>If what you=
 want to do is just&nbsp;lose data as little as possible, and perf isn't a =
problem for you, then some sort of big int variable length integer class wo=
uld do the job.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(=
204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;"><div>&nbsp;</div><div>I would note that the=
re could be a middle ground, though it may be tricky to get to compile. You=
 could say that for SafeInt of types smaller than int, then the return woul=
d be SafeInt&lt;int&gt;</div></blockquote><div><br>This is very interesting=
..&nbsp; When I started on this, I started with "save_range&lt;min, max&gt;"=
 from which safe&lt;int&gt; is derived.&nbsp; This left open the possibilit=
y of using safe_range&lt;0, 4&gt; * safe_range&lt;0,8&gt;&nbsp; to return a=
 safe_range&lt;0, 12&gt; which was very cool to me.&nbsp; But the TMP got j=
ust to complex and I scaled back my so that safe_range&lt;0,4&gt; is implem=
ented as a safe&lt;unsigned char&gt; etc.<br><br></div></blockquote><div>&n=
bsp;</div><div>This could be done, but you'd have to do a partial template =
specialization over the entire class, and you'd end up with multiple versio=
ns of all the members. While it is enticing from an academic standpoint, fr=
om a work needed to implement standpoint, it is tough to justify. And in pr=
actice, we're most often working with 32-bit instances, second most frequen=
t case is mixed 32 and 64-bit.</div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_23_18377105.1354135547286--

.

------=_Part_21_2836069.1354136227431
Content-Type: text/plain; charset=ISO-8859-1


On Wednesday, November 28, 2012 4:08:38 AM UTC-8, Fernando Cacciola wrote:
>
> On Wed, Nov 28, 2012 at 12:22 AM, <dvd_l...@yahoo.com <javascript:>>wrote:
>
>> I agree that there are two separate goals. One is to avoid overflow by
>> promoting to the next integer This would reach bigint in the end. The other
>> is to turn overflow into well defined and *useful* behavior, but without
>> any need to avoid it, just to deal with it.
>>
>> From your use cases I can see that SafeInt is aimed at the later. The
>> uses I have in mind are closer to the former.
>>
>> So, IMO a proposal should contemplate both, and possibly, provide
>> utilities to both problems.
>>
>
Yes, agreed. I have done numerical analysis in the past, which is where I
first became sensitive to this problem. Once I realized that was your frame
of reference, many of your comments became more clear.


>
>>
> What is undefined is the case of SafeInt<T> op SafeInt<U>. I don't know
>> what type you want back, and compilers tend to just throw up their hands
>> and refuse to compile. You could have a large table of all the types, but
>> that's ugly. So I then ask you to make up your mind and do for example
>> (U)SafeInt<T> op SafeInt<U>.
>>
>>
>
> Integer types are ranked based on their ranges. That's used in integer
> promotion. IMO, it's perfectly valid and I would say simple to define
> similar promotion rules for SafeInt<T> op SafeInt<U> based on the operation.
>
>
If you don't specialize them out, then you cannot get this to compile. I
could theoretically have 64 specializations per binary operator (possibly
omitting things like shift). You would also run into problems with things
like:

- (SafeInt<int>(x) * SafeInt<unsigned int>(y))

If we followed standard casting rules, the multiplication would yield a
SafeInt<unsigned int>, and then when we went to negate it, it will a)
throw, and b) be doing something undefined by the standard and subject to
having some compilers just toss your expression out completely.

While I do like the overall approach, and have spent a good bit of time
attempting to sort out how it might work, things like this give me
headaches and I decided shipping was a cool feature. In practice, you do
not see this happen often.

--




------=_Part_21_2836069.1354136227431
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Wednesday, November 28, 2012 4:08:38 AM UTC-8, Fernando Cacciola wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;"><div><div class=3D"gmail_quote">On Wed, Nov=
 28, 2012 at 12:22 AM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"1XfAOUOLYQgJ">dvd_l...@yahoo.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;">

<div>I agree that there are two separate goals. One is to avoid overflow by=
 promoting to the next integer This would reach bigint in the end. The othe=
r is to turn overflow into well defined and *useful* behavior, but without =
any need to avoid it, just to deal with it.<br>

<br>From your use cases I can see that SafeInt is aimed at the later. The u=
ses I have in mind are closer to the former.<br><br>So, IMO a proposal shou=
ld contemplate both, and possibly, provide utilities to both problems.<br>

</div></blockquote></div></div></blockquote><div>&nbsp;</div><div>Yes, agre=
ed. I have done numerical analysis in the past, which is where I first beca=
me sensitive to this problem. Once I realized that was your frame of refere=
nce, many of your comments became more clear.</div><div>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;"><div><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-=
left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: =
solid;"><div>&nbsp;</div></blockquote><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(=
204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div>Wha=
t is undefined is the case of SafeInt&lt;T&gt; op SafeInt&lt;U&gt;. I don't=
 know what type you want back,&nbsp;and compilers tend to just throw up the=
ir hands and refuse to compile. You could have a large table of all the typ=
es, but that's ugly. So I then ask you to make up your mind and do for exam=
ple (U)SafeInt&lt;T&gt; op SafeInt&lt;U&gt;.</div>

<div><div>&nbsp;&nbsp;</div></div></blockquote><div><br>Integer types are r=
anked based on their ranges. That's used in integer promotion. IMO, it's pe=
rfectly valid and I would say simple to define similar promotion rules for =
SafeInt&lt;T&gt; op SafeInt&lt;U&gt; based on the operation.<br>

<br></div></div></div></blockquote><div>&nbsp;</div><div>If you don't speci=
alize them out, then you cannot get this to compile. I could theoretically =
have 64 specializations per binary operator (possibly omitting things like =
shift). You would also run into problems with things like:</div><div>&nbsp;=
</div><div>- (SafeInt&lt;int&gt;(x) * SafeInt&lt;unsigned int&gt;(y))</div>=
<div>&nbsp;</div><div>If we followed standard casting rules, the multiplica=
tion would yield a SafeInt&lt;unsigned int&gt;, and then when we went to ne=
gate it, it will a) throw, and b) be doing something undefined by the stand=
ard and subject to having some compilers just toss your expression out comp=
letely.</div><div>&nbsp;</div><div>While I do like the overall approach, an=
d have spent a good bit of time attempting to sort out how it might work, t=
hings like this give me headaches and I decided shipping was a cool feature=
.. In practice, you do not see this happen often.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_21_2836069.1354136227431--

.

------=_Part_46_9360358.1354136799688
Content-Type: text/plain; charset=ISO-8859-1


On Wednesday, November 28, 2012 5:23:56 AM UTC-8, Fernando Cacciola wrote:
>
> On Wed, Nov 28, 2012 at 12:01 AM, <dvd_l...@yahoo.com <javascript:>>wrote:
>
>>
>> Thanks, then yes, we agree on that. However, you would need both throwing
>> and non-throwing semantics, as you see in the code. The throwing semantics
>> can sometimes have a cleaner failure path.
>>
>
> IIUC, this is because you have failure policies.
> If, OTOH, the library just consistently throw as the sole overflow
> handling mechanism, you won't need both.
>
> I would (and probably will) argue that, a *standard library utility*
> should just consistently throw. Or else, something at a wider lever, across
> libraries, should be proposed.
>
>
There are two counter-points - first is that while it is nice to throw,
is it nicer to allow the caller to decide what to throw. It makes it a lot
easier to use this class where either there are existing exception classes
you'd like to integrate with, and it makes it easier if you'd prefer to
just take the app down. In the Windows-specific case, we sometimes have
code which isn't set up with exception handlers, and you might choose to
use Windows exceptions. On UNIX, you could do similar things with signals.

The other is that throwing and catching an exception is very expensive. If
we think that failure cases could be common, then we are a lot better off
with a function that performs the addition and returns a status. We also
would like to have tools to solve the problem where we may not be allowed
to use exceptions - for example, in the kernel.


> I'm certainly willing to discuss the idea - one possibility is that our
>> implementation or design was bad.
>>
>
> IME, most thoughtful implementations and designs are not bad, but can be
> improved as new use cases or updated requirements are discovered.
>

Fair enough.


--




------=_Part_46_9360358.1354136799688
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Wednesday, November 28, 2012 5:23:56 AM UTC-8, Fernando Cacciola wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;"><div><div class=3D"gmail_quote">On Wed, Nov=
 28, 2012 at 12:01 AM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"gjUmTkb--vYJ">dvd_l...@yahoo.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;">

<div><br>Thanks, then yes, we agree on that. However, you would need both t=
hrowing and non-throwing semantics, as you see in the code. The throwing se=
mantics can sometimes have a&nbsp;cleaner failure path.</div>

</blockquote><div><br>IIUC, this is because you have failure policies.<br>I=
f, OTOH, the library just consistently throw as the sole overflow handling =
mechanism, you won't need both.<br><br>I would (and probably will) argue th=
at, a *standard library utility* should just consistently throw. Or else, s=
omething at a wider lever, across libraries, should be proposed.<br>

&nbsp;<br></div></div></div></blockquote><div>There are two counter-points =
- first is that while it is nice to throw, is&nbsp;it nicer to allow the ca=
ller to decide what to throw. It makes it a lot easier to use this class wh=
ere either there are existing exception classes you'd like to integrate wit=
h, and it makes it easier if you'd prefer to just take the app down. In the=
 Windows-specific case, we sometimes have code which isn't set up with exce=
ption handlers, and you might choose to use Windows exceptions. On UNIX, yo=
u could do similar things with signals.</div><div>&nbsp;</div><div>The othe=
r is that throwing and catching an exception is very expensive. If we think=
 that failure cases could be common, then we are a lot better off with a fu=
nction that performs the addition and returns a status. We also would like =
to have tools to solve the problem where we may not be allowed to use excep=
tions - for example, in the kernel.</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color=
: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><d=
iv>I'm certainly willing to discuss the idea - one possibility is that our =
implementation or design was bad. </div>

</blockquote><div><br>IME, most thoughtful implementations and designs are =
not bad, but can be improved as new use cases or updated requirements are d=
iscovered. <br></div></div></div></blockquote><div>&nbsp;</div><div>Fair en=
ough.</div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_46_9360358.1354136799688--

.

------=_Part_40_32563977.1354137451952
Content-Type: text/plain; charset=ISO-8859-1


On Wednesday, November 28, 2012 9:03:02 AM UTC-8, Chris Jefferson wrote:
>
>  I use my own safeint extensively, and find it to be very useful in
> protecting from various kinds of overflow.
>
> There is (in my opinion) one major design flaw in safeint, namely the
> operators like:
>
> 'operator int() const', which allow the safeint to be turned back into an
> int, for function calls. I prefer having a member function 'x.raw()', or
> new function 'checked_cast<int>(x)'. This does make code using safeint much
> more verbose, but means you cannot accidentally invoke unsafe behaviour, by
> turning back into non-safe types.
>
>
Yes, this is a trade-off. The problem is that it then prevents you from
using temporaries in a lot of common cases. For example:

Foo(SafeInt<int>(x) * 2);

This was a debated design decision, and is not by accident. Another much
more serious problem is that the raw approach lends itself to abuse, like
so:

template <typename T>
T SafeInt<T>::raw() const { return m_int; }

People then call this, and any further casts, say on entry into the
function now become unsafe. Or perhaps the signature of the function
changes, it is nice if the SafeInt parameter will then check casting to
match. This is a problem we have seen with some of the C-style integer
libraries - people check one operation when they should have checked three.

I agree that overloaded casting operators are in general treacherous, but
in this case it results in safe code more often, which is the primary goal.




> I feel if someone is going to the effort of using safeint, then they
> should care both when values are turned into safeint, and turned back.
> However, this goes get particularly annoying when doing things like
> indexing vectors, where you must keep writing 'v[x.raw()]' all the time.
>
>
Actually, that case is annoying either way. I cannot figure out why
(perhaps a compiler bug?) the compiler does not just attempt a cast to
ptrdiff_t when used as an index, but I do have to extract the underlying
int to use it as an index.


--




------=_Part_40_32563977.1354137451952
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Wednesday, November 28, 2012 9:03:02 AM UTC-8, Chris Jefferson wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>I use my own safeint extensively, and
      find it to be very useful in protecting from various kinds of
      overflow.<br>
      <br>
      There is (in my opinion) one major design flaw in safeint, namely
      the operators like:<br>
      <br>
      'operator int() const', which allow the safeint to be turned back
      into an int, for function calls. I prefer having a member function
      'x.raw()', or new function 'checked_cast&lt;int&gt;(x)'. This does
      make code using safeint much more verbose, but means you cannot
      accidentally invoke unsafe behaviour, by turning back into
      non-safe types.<br>
      <br></div></div></blockquote><div>&nbsp;</div><div>Yes, this is a tra=
de-off. The problem is that it then prevents you from using temporaries in =
a lot of common cases. For example:</div><div>&nbsp;</div><div>Foo(SafeInt&=
lt;int&gt;(x) * 2);</div><div>&nbsp;</div><div>This was a debated design de=
cision, and is not by accident. Another much more serious problem is that t=
he raw approach lends itself to abuse, like so:</div><div>&nbsp;</div><div>=
template &lt;typename T&gt;</div><div>T SafeInt&lt;T&gt;::raw() const { ret=
urn m_int; }</div><div>&nbsp;</div><div>People then call this, and any furt=
her casts, say on entry into the function now become unsafe. Or perhaps the=
 signature of the function changes, it is nice if the SafeInt parameter wil=
l then check casting to match. This is a problem we have seen with some of =
the C-style integer libraries - people check one operation when they should=
 have checked three.</div><div>&nbsp;</div><div>I agree that overloaded cas=
ting operators are in general treacherous, but in this case it results in s=
afe code more often, which is the primary goal.</div><div>&nbsp;</div><div>=
&nbsp;</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204,=
 204); border-left-width: 1px; border-left-style: solid;"><div text=3D"#000=
000" bgcolor=3D"#FFFFFF"><div>
      I feel if someone is going to the effort of using safeint, then
      they should care both when values are turned into safeint, and
      turned back. However, this goes get particularly annoying when
      doing things like indexing vectors, where you must keep writing
      'v[x.raw()]' all the time.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </div></div></blockquote><div>Actually, that=
 case is annoying either way. I cannot figure out why (perhaps a compiler b=
ug?) the compiler does not just attempt a cast to ptrdiff_t when used as an=
 index, but I do have to extract the underlying int to use it as an index.<=
/div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_40_32563977.1354137451952--

.

--047d7b3436a24ce68d04cf94f9ea
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 28, 2012 at 5:45 PM, <dvd_leblanc@yahoo.com> wrote:

>
> On Tuesday, November 27, 2012 11:37:34 PM UTC-8, robertmac...@gmail.comwrote:
>>
>>
>>
>>>
>>> Ah - from the standpoint of keeping things from overflowing, I would
>>> tend to agree. From the standpoint of being able to use it in production
>>> code because I have not caused a perf problem, I disagree.
>>>
>>
>> I'm not convinced that promoting the types to 64 bits is more expensive
>> timewise than the alternatives. I'd have to see some real data on that.
>>
>> OK, so looking at the case of
>

While all the facts in your analysis are correct, I think the conclusion is
not that clear.

The issue is this:

Consider a type T which is the largest natural integer in a given platform.
Now consider integer types U1, U2, U3 etc all of which are smaller than T.

Further, let's assume that the most efficient and clean way to implement
*the test for overflow* for a given operation between SafeInt<Un> is to
promote both operands to Un+1 (restricting this implementation technique to
types smaller than T). AFAICT this is exactly what SafeInt as well as
Rober's safe<> do, so it's sensible assumption.

Since the implementation is *already* performing the promotion to the next
integer type in order to efficiently test for overflow, it is IMO a total
waste to don't just return that perfectly exact and in-range value, and
instead sort-of *cause* the overflow by unnecessarily downcasting to the
operands type.

OTOH, if we are operating on T then an implementation might very well not
use an expensive 2T to test for overflow, in which case your analysis
applies and it would more efficient to test for the overflow in a different
way.

So, it seems to me that automatically promoting up to a certain
implementation-defined type is both useful and efficient. Beyond that type,
different application domains would benefit from one or other solution,
thus like I said I would like a proposal to provide both, or at least leave
a sensible path for a separate proposal to complete the offering.




--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--047d7b3436a24ce68d04cf94f9ea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Nov 28, 2=
012 at 5:45 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:dvd_leblanc@yahoo.=
com" target=3D"_blank">dvd_leblanc@yahoo.com</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">

<div class=3D"im"><br>On Tuesday, November 27, 2012 11:37:34 PM UTC-8, <a h=
ref=3D"mailto:robertmac...@gmail.com" target=3D"_blank">robertmac...@gmail.=
com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-widt=
h:1px;border-left-style:solid">

<br>=A0<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;b=
order-left-style:solid"><div>Ah - from the standpoint of keeping things fro=
m overflowing, I would tend to agree. From the standpoint of being able to =
use it in production code because I have not caused a perf problem, I disag=
ree.</div>

</blockquote><div><br>I&#39;m not convinced that promoting the types to 64 =
bits is more expensive timewise than the alternatives. I&#39;d have to see =
some real data on that.<br><br></div></blockquote></div><div>OK, so looking=
 at the=A0case of </div>

</blockquote><div><br>While all the facts in your analysis are correct, I t=
hink the conclusion is not that clear.<br><br>The issue is this:<br><br>Con=
sider a type T which is the largest natural integer in a given platform. No=
w consider integer types U1, U2, U3 etc all of which are smaller than T.<br=
>

<br>Further, let&#39;s assume that the most efficient and clean way to impl=
ement *the test for overflow* for a given operation between SafeInt&lt;Un&g=
t; is to promote both operands to Un+1 (restricting this implementation tec=
hnique to types smaller than T). AFAICT this is exactly what SafeInt as wel=
l as Rober&#39;s safe&lt;&gt; do, so it&#39;s sensible assumption.<br>

<br>Since the implementation is *already* performing the promotion to the n=
ext integer type in order to efficiently test for overflow, it is IMO a tot=
al waste to don&#39;t just return that perfectly exact and in-range value, =
and instead sort-of *cause* the overflow by unnecessarily downcasting to th=
e operands type.<br>

<br>OTOH, if we are operating on T then an implementation might very well n=
ot use an expensive 2T to test for overflow, in which case your analysis ap=
plies and it would more efficient to test for the overflow in a different w=
ay.<br>

<br>So, it seems to me that automatically promoting up to a certain impleme=
ntation-defined type is both useful and efficient. Beyond that type, differ=
ent application domains would benefit from one or other solution, thus like=
 I said I would like a proposal to provide both, or at least leave a sensib=
le path for a separate proposal to complete the offering.<br>

<br></div></div><br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSo=
ft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">htt=
p://www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3436a24ce68d04cf94f9ea--

.

--e89a8f923f3aea804904cf950af0
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 28, 2012 at 5:57 PM, <dvd_leblanc@yahoo.com> wrote:

>
> On Wednesday, November 28, 2012 4:08:38 AM UTC-8, Fernando Cacciola wrote:
>
>> On Wed, Nov 28, 2012 at 12:22 AM, <dvd_l...@yahoo.com> wrote:
>>
>>> I agree that there are two separate goals. One is to avoid overflow by
>>> promoting to the next integer This would reach bigint in the end. The other
>>> is to turn overflow into well defined and *useful* behavior, but without
>>> any need to avoid it, just to deal with it.
>>>
>>> From your use cases I can see that SafeInt is aimed at the later. The
>>> uses I have in mind are closer to the former.
>>>
>>> So, IMO a proposal should contemplate both, and possibly, provide
>>> utilities to both problems.
>>>
>>
> Yes, agreed. I have done numerical analysis in the past, which is where I
> first became sensitive to this problem. Once I realized that was your frame
> of reference, many of your comments became more clear.
>
>
>>
>>>
>> What is undefined is the case of SafeInt<T> op SafeInt<U>. I don't know
>>> what type you want back, and compilers tend to just throw up their hands
>>> and refuse to compile. You could have a large table of all the types, but
>>> that's ugly. So I then ask you to make up your mind and do for example
>>> (U)SafeInt<T> op SafeInt<U>.
>>>
>>>
>>
>> Integer types are ranked based on their ranges. That's used in integer
>> promotion. IMO, it's perfectly valid and I would say simple to define
>> similar promotion rules for SafeInt<T> op SafeInt<U> based on the operation.
>>
>>
> If you don't specialize them out, then you cannot get this to compile. I
> could theoretically have 64 specializations per binary operator (possibly
> omitting things like shift). You would also run into problems with things
> like:
>
> - (SafeInt<int>(x) * SafeInt<unsigned int>(y))
>
> If we followed standard casting rules, the multiplication would yield a
> SafeInt<unsigned int>, and then when we went to negate it, it will a)
> throw, and b) be doing something undefined by the standard and subject to
> having some compilers just toss your expression out completely.
>
> While I do like the overall approach, and have spent a good bit of time
> attempting to sort out how it might work, things like this give me
> headaches and I decided shipping was a cool feature. In practice, you do
> not see this happen often.
>

OK.

Now following up on my latest response, I would still say that a certain
"logical path" of automatic promotions are reasonable. The proposal could
only contemplete those which are evidently reasonable, and leave all other
cases in the wat SafeInt<> is now.

This seems like a balance between your's and Robert's approaches.



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--e89a8f923f3aea804904cf950af0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, Nov 28, 2012 =
at 5:57 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:dvd_leblanc@yahoo.com"=
 target=3D"_blank">dvd_leblanc@yahoo.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">

<br>On Wednesday, November 28, 2012 4:08:38 AM UTC-8, Fernando Cacciola wro=
te:<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-le=
ft-width:1px;border-left-style:solid">

<div><div class=3D"gmail_quote">On Wed, Nov 28, 2012 at 12:22 AM,  <span di=
r=3D"ltr">&lt;<a>dvd_l...@yahoo.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bord=
er-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:soli=
d">



<div>I agree that there are two separate goals. One is to avoid overflow by=
 promoting to the next integer This would reach bigint in the end. The othe=
r is to turn overflow into well defined and *useful* behavior, but without =
any need to avoid it, just to deal with it.<br>



<br>From your use cases I can see that SafeInt is aimed at the later. The u=
ses I have in mind are closer to the former.<br><br>So, IMO a proposal shou=
ld contemplate both, and possibly, provide utilities to both problems.<br>



</div></blockquote></div></div></blockquote><div>=A0</div></div><div>Yes, a=
greed. I have done numerical analysis in the past, which is where I first b=
ecame sensitive to this problem. Once I realized that was your frame of ref=
erence, many of your comments became more clear.</div>

<div class=3D"im"><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div><div class=3D"gmail_q=
uote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div>=A0</div></blockquote><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb=
(204,204,204);border-left-width:1px;border-left-style:solid">

<div>What is undefined is the case of SafeInt&lt;T&gt; op SafeInt&lt;U&gt;.=
 I don&#39;t know what type you want back,=A0and compilers tend to just thr=
ow up their hands and refuse to compile. You could have a large table of al=
l the types, but that&#39;s ugly. So I then ask you to make up your mind an=
d do for example (U)SafeInt&lt;T&gt; op SafeInt&lt;U&gt;.</div>



<div><div>=A0=A0</div></div></blockquote><div><br>Integer types are ranked =
based on their ranges. That&#39;s used in integer promotion. IMO, it&#39;s =
perfectly valid and I would say simple to define similar promotion rules fo=
r SafeInt&lt;T&gt; op SafeInt&lt;U&gt; based on the operation.<br>



<br></div></div></div></blockquote><div>=A0</div></div><div>If you don&#39;=
t specialize them out, then you cannot get this to compile. I could theoret=
ically have 64 specializations per binary operator (possibly omitting thing=
s like shift). You would also run into problems with things like:</div>

<div>=A0</div><div>- (SafeInt&lt;int&gt;(x) * SafeInt&lt;unsigned int&gt;(y=
))</div><div>=A0</div><div>If we followed standard casting rules, the multi=
plication would yield a SafeInt&lt;unsigned int&gt;, and then when we went =
to negate it, it will a) throw, and b) be doing something undefined by the =
standard and subject to having some compilers just toss your expression out=
 completely.</div>

<div>=A0</div><div>While I do like the overall approach, and have spent a g=
ood bit of time attempting to sort out how it might work, things like this =
give me headaches and I decided shipping was a cool feature. In practice, y=
ou do not see this happen often.</div>

</blockquote><div><br>OK.<br><br>Now following up on my latest response, I =
would still say that a certain &quot;logical path&quot; of automatic promot=
ions are reasonable. The proposal could only contemplete those which are ev=
idently reasonable, and leave all other cases in the wat SafeInt&lt;&gt; is=
 now.<br>

<br>This seems like a balance between your&#39;s and Robert&#39;s approache=
s.<br></div></div><br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>Sci=
Soft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">h=
ttp://www.scisoft-consulting.com</a><br>


</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f923f3aea804904cf950af0--

.

------=_Part_73_25570256.1354142848484
Content-Type: text/plain; charset=ISO-8859-1


On Wednesday, November 28, 2012 1:36:50 PM UTC-8, Fernando Cacciola wrote:
>
>
> OTOH, if we are operating on T then an implementation might very well not
> use an expensive 2T to test for overflow, in which case your analysis
> applies and it would more efficient to test for the overflow in a different
> way.
>
> So, it seems to me that automatically promoting up to a certain
> implementation-defined type is both useful and efficient. Beyond that type,
> different application domains would benefit from one or other solution,
> thus like I said I would like a proposal to provide both, or at least leave
> a sensible path for a separate proposal to complete the offering.
>
> In practice, there are two things to observe - first is that operations
on int16 are some of the most risky. It may be hard to get 4 billion of
something, but not that hard to exceed 64k. The second is that the typical
case is most often 32 and 64-bit integers.

I see benefits and drawbacks to both approaches. So for example, consider a
chain of unsigned int16 additions and subtractions. The current
implementation has the drawback of not dealing with ( 4 - 5 + 6 ).
Promoting to an int would solve this, and be consistent with operator
casting. The drawback of this is that it is very cheap to check whether an
unsigned addition worked as expected, and not cheap at all to determine if
(int + int) worked. From a perf standpoint, we prefer to avoid signed
numbers - these are always more difficult to check.

From a programming standpoint, it is relatively straightforward to
specialize for the five types which are smaller than int in normal modern
use. But if we are talking about the standard, now nothing is guaranteed -
we know that sizeof(char) is 1, but can infer nothing about short, int,
long, and long long. So it would be tricky to make the specializations work
correctly if we cannot make assumptions about relative sizes - can likely
overcome some of this by making yet another set of cases where we determine
register size with sizeof(size_t), and can then go from there.

Even so, following the standard promotion rules can still get us into
trouble, since short + unsigned short yields and int, but int + unsigned
int yields an unsigned int, and not a long long (as C# does, and IMHO, the
standard ought to have promotion rules that don't have exceptions in the
middle).

I'm tempted by the benefits of special casing for sizeof(type) <
sizeof(int), but I am wary of the perf implications.

--




------=_Part_73_25570256.1354142848484
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Wednesday, November 28, 2012 1:36:50 PM UTC-8, Fernando Cacciola wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;"><div><br><div class=3D"gmail_quote"><div>OT=
OH, if we are operating on T then an implementation might very well not use=
 an expensive 2T to test for overflow, in which case your analysis applies =
and it would more efficient to test for the overflow in a different way.<br=
>

<br>So, it seems to me that automatically promoting up to a certain impleme=
ntation-defined type is both useful and efficient. Beyond that type, differ=
ent application domains would benefit from one or other solution, thus like=
 I said I would like a proposal to provide both, or at least leave a sensib=
le path for a separate proposal to complete the offering.<br>

<br></div></div></div></blockquote><div>In practice, there are two things t=
o observe - first is that operations on&nbsp;int16 are some of the most ris=
ky. It may be hard to get 4 billion of something, but not that hard to exce=
ed 64k. The second is that the typical case is most often 32 and 64-bit int=
egers.</div><div>&nbsp;</div><div>I see benefits and drawbacks to both appr=
oaches. So for example, consider a chain of unsigned int16 additions and su=
btractions. The current implementation has the drawback of not dealing with=
 ( 4 - 5 + 6 ). Promoting to an int would solve this, and be consistent wit=
h operator casting. The drawback of this is that it is very cheap to check =
whether an unsigned addition worked as expected, and not cheap at all to de=
termine if (int + int) worked. From a perf standpoint, we prefer to avoid s=
igned numbers - these are always more difficult to check.</div><div>&nbsp;<=
/div><div>From a programming standpoint, it is relatively straightforward t=
o specialize for the five types which are&nbsp;smaller than int in normal m=
odern use. But if we are talking about the standard, now nothing is guarant=
eed - we know that&nbsp;sizeof(char) is 1, but can infer nothing about shor=
t, int, long, and long long. So it would be tricky to make the specializati=
ons work correctly if we cannot make assumptions about relative sizes - can=
 likely overcome some of this by making yet another set of cases where we d=
etermine register size with sizeof(size_t), and can then go from there.<br>=
<br>Even so, following the standard promotion rules can still get us into t=
rouble, since short + unsigned short yields and int, but int + unsigned int=
 yields an unsigned int, and not a long long (as C# does, and IMHO, the sta=
ndard ought to have promotion rules that don't have exceptions in the middl=
e).</div><div>&nbsp;</div><div>I'm tempted by the benefits of special casin=
g for sizeof(type) &lt; sizeof(int), but I am wary of the perf implications=
..</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_73_25570256.1354142848484--

.

On 11/27/12, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> On Nov 26, 2012 Lawrence Crowl <crowl@googlers.com> wrote:
> > On 11/23/12, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> > > Both fixed_point<T> and rational<T> are useful as long
> > > as the values do not overflow. However, and this is
> > > particularly true in the case of rationals, there are
> > > several application domains where computations can easily,
> > > and often, overflow. In these cases, one must use a big_int
> > > (unlimited precision integer) as T (whether for a fixed_point
> > > or rational) But that is pessimistically inefficient, so
> > > one would consider a non-template "exact" numeric type which
> > > would have a dynamic internal representation of rational<T>
> > > but which would automatically switch from T to 2T (meaning
> > > a two times bigger integer), until it reaches big_int.
> >
> > The study group has reached a tentative conclusion that a
> > rational should be based either on a bigint, or do rounding
> > when the representation is not sufficient for the true result.
> > The former would be useful in computational geometry.  The latter
> > would be useful in music.
>
> I agree. Well almost.  There are significant efficiency concerns
> when using bigint, and I think that in C++ it's possible to
> overcome that by means of a mechanism that promotes to "the next
> most efficient integer type needed" as computations are performed.
> Something of this form has been done, sort of manually, over
> the past decade or more, in different unrelated projects, and it
> would be fantastic to capture some of that within standard C++

The committee was leaning towards a tagged representation for bigint,
enabling fast single-word storage for the bulk of actual values.
Of course, the standard itself rarely defines representations.
We just need to make sure the standard permits good ones, and the
market will do the rest.

--
Lawrence Crowl

--




.

--e89a8f923f3a526bde04cf96ac1f
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 28, 2012 at 8:26 PM, Lawrence Crowl <crowl@googlers.com> wrote:

> On 11/27/12, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> > On Nov 26, 2012 Lawrence Crowl <crowl@googlers.com> wrote:
> > > On 11/23/12, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> > > > Both fixed_point<T> and rational<T> are useful as long
> > > > as the values do not overflow. However, and this is
> > > > particularly true in the case of rationals, there are
> > > > several application domains where computations can easily,
> > > > and often, overflow. In these cases, one must use a big_int
> > > > (unlimited precision integer) as T (whether for a fixed_point
> > > > or rational) But that is pessimistically inefficient, so
> > > > one would consider a non-template "exact" numeric type which
> > > > would have a dynamic internal representation of rational<T>
> > > > but which would automatically switch from T to 2T (meaning
> > > > a two times bigger integer), until it reaches big_int.
> > >
> > > The study group has reached a tentative conclusion that a
> > > rational should be based either on a bigint, or do rounding
> > > when the representation is not sufficient for the true result.
> > > The former would be useful in computational geometry.  The latter
> > > would be useful in music.
> >
> > I agree. Well almost.  There are significant efficiency concerns
> > when using bigint, and I think that in C++ it's possible to
> > overcome that by means of a mechanism that promotes to "the next
> > most efficient integer type needed" as computations are performed.
> > Something of this form has been done, sort of manually, over
> > the past decade or more, in different unrelated projects, and it
> > would be fantastic to capture some of that within standard C++
>
> The committee was leaning towards a tagged representation for bigint,
> enabling fast single-word storage for the bulk of actual values.
> Of course, the standard itself rarely defines representations.
> We just need to make sure the standard permits good ones, and the
> market will do the rest.
>
>
Fantastic.

Don't know the details but I'm pleased to see that we won't just take the
simplistic route and merely standardize some of the big integers that have
been around for more than a decade. They get the job done, some with an
incredible amount of crafted optimization (take GMP's mpz_t  for example),
yet they are still not as good as C++ ought to offer (IMO).





--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




--e89a8f923f3a526bde04cf96ac1f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, Nov 28, 2012 =
at 8:26 PM, Lawrence Crowl <span dir=3D"ltr">&lt;<a href=3D"mailto:crowl@go=
oglers.com" target=3D"_blank">crowl@googlers.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

On 11/27/12, Fernando Cacciola &lt;<a href=3D"mailto:fernando.cacciola@gmai=
l.com">fernando.cacciola@gmail.com</a>&gt; wrote:<br>
<div class=3D"im">&gt; On Nov 26, 2012 Lawrence Crowl &lt;<a href=3D"mailto=
:crowl@googlers.com">crowl@googlers.com</a>&gt; wrote:<br>
&gt; &gt; On 11/23/12, Fernando Cacciola &lt;<a href=3D"mailto:fernando.cac=
ciola@gmail.com">fernando.cacciola@gmail.com</a>&gt; wrote:<br>
</div><div class=3D"im">&gt; &gt; &gt; Both fixed_point&lt;T&gt; and ration=
al&lt;T&gt; are useful as long<br>
&gt; &gt; &gt; as the values do not overflow. However, and this is<br>
&gt; &gt; &gt; particularly true in the case of rationals, there are<br>
&gt; &gt; &gt; several application domains where computations can easily,<b=
r>
&gt; &gt; &gt; and often, overflow. In these cases, one must use a big_int<=
br>
&gt; &gt; &gt; (unlimited precision integer) as T (whether for a fixed_poin=
t<br>
&gt; &gt; &gt; or rational) But that is pessimistically inefficient, so<br>
&gt; &gt; &gt; one would consider a non-template &quot;exact&quot; numeric =
type which<br>
&gt; &gt; &gt; would have a dynamic internal representation of rational&lt;=
T&gt;<br>
&gt; &gt; &gt; but which would automatically switch from T to 2T (meaning<b=
r>
&gt; &gt; &gt; a two times bigger integer), until it reaches big_int.<br>
&gt; &gt;<br>
&gt; &gt; The study group has reached a tentative conclusion that a<br>
&gt; &gt; rational should be based either on a bigint, or do rounding<br>
&gt; &gt; when the representation is not sufficient for the true result.<br=
>
&gt; &gt; The former would be useful in computational geometry. =A0The latt=
er<br>
&gt; &gt; would be useful in music.<br>
&gt;<br>
&gt; I agree. Well almost. =A0There are significant efficiency concerns<br>
&gt; when using bigint, and I think that in C++ it&#39;s possible to<br>
&gt; overcome that by means of a mechanism that promotes to &quot;the next<=
br>
&gt; most efficient integer type needed&quot; as computations are performed=
..<br>
&gt; Something of this form has been done, sort of manually, over<br>
&gt; the past decade or more, in different unrelated projects, and it<br>
&gt; would be fantastic to capture some of that within standard C++<br>
<br>
</div>The committee was leaning towards a tagged representation for bigint,=
<br>
enabling fast single-word storage for the bulk of actual values.<br>
Of course, the standard itself rarely defines representations.<br>
We just need to make sure the standard permits good ones, and the<br>
market will do the rest.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br>Fantastic.<br><br>Don&#39;t know the details but I&#39;m please=
d to see that we won&#39;t just take the simplistic route and merely standa=
rdize some of the big integers that have been around for more than a decade=
.. They get the job done, some with an incredible amount of crafted optimiza=
tion (take GMP&#39;s mpz_t=A0 for example), yet they are still not as good =
as C++ ought to offer (IMO).<br>

<br>=A0<br></div></div><br><br clear=3D"all"><br>-- <br>Fernando Cacciola<b=
r>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.c=
om">http://www.scisoft-consulting.com</a><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f923f3a526bde04cf96ac1f--

.