mirror of
https://github.com/boostorg/safe_numerics.git
synced 2026-02-22 03:32:24 +00:00
improved TOC and chunking. This is complicated by the fact we that we desire different depths. put copies of boost logo in subdirectories
202 lines
10 KiB
HTML
202 lines
10 KiB
HTML
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
|
|
<title>Rationale and FAQ</title>
|
|
<link rel="stylesheet" href="boostbook.css" type="text/css">
|
|
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
|
|
<link rel="home" href="index.html" title="Safe Numerics">
|
|
<link rel="up" href="index.html" title="Safe Numerics">
|
|
<link rel="prev" href="performance_tests.html" title="Performance Tests">
|
|
<link rel="next" href="pending_issues.html" title="Pending Issues">
|
|
</head>
|
|
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
|
|
<table cellpadding="2" width="100%"><tr>
|
|
<td valign="top"><img href="index.html" height="164px" src="pre-boost.jpg" alt="Library Documentation Index"></td>
|
|
<td><h2>Safe Numerics</h2></td>
|
|
</tr></table>
|
|
<div class="spirit-nav">
|
|
<a accesskey="p" href="performance_tests.html"><img src="images/prev.png" alt="Prev"></a><a accesskey="u" href="index.html"><img src="images/up.png" alt="Up"></a><a accesskey="h" href="index.html"><img src="images/home.png" alt="Home"></a><a accesskey="n" href="pending_issues.html"><img src="images/next.png" alt="Next"></a>
|
|
</div>
|
|
<div class="section">
|
|
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
|
|
<a name="safe_numerics.rationale"></a>Rationale and FAQ</h2></div></div></div>
|
|
<div class="qandaset">
|
|
<a name="idm413202553024"></a><dl>
|
|
<dt>1. <a href="rationale.html#idm413202552528">Is this really necessary? If I'm writing the program with the
|
|
requisite care and competence, problems noted in the introduction
|
|
will never arise. Should they arise, they should be fixed "at the
|
|
source" and not with a "band aid" to cover up bad practice.</a>
|
|
</dt>
|
|
<dt>2. <a href="rationale.html#idm413202549216">Why is Boost.Convert not used?</a>
|
|
</dt>
|
|
<dt>3. <a href="rationale.html#idm413202547216">Why is the library named "safe ..." rather than something like
|
|
"checked ..." ?</a>
|
|
</dt>
|
|
<dt>4. <a href="rationale.html#idm413202544848">Given that the library is called "numerics" why is floating
|
|
point arithmetic not addressed?</a>
|
|
</dt>
|
|
<dt>5. <a href="rationale.html#idm413202542528">Isn't putting a defensive check just before any potential
|
|
undefined behavior is often considered a bad practice?</a>
|
|
</dt>
|
|
<dt>6. <a href="rationale.html#idm413202538928">It looks like the implementation presumes two's complement
|
|
arithmetic at the hardware level. So this library is not portable -
|
|
correct? What about other hardware architectures?</a>
|
|
</dt>
|
|
<dt>7. <a href="rationale.html#idm413202536592">Why do you specialize numeric_limits for "safe" types? Do you
|
|
need it?</a>
|
|
</dt>
|
|
<dt>8. <a href="rationale.html#idm413202534224">According to C/C++ standards, unsigned integers cannot
|
|
overflow - they are modular integers which "warp around". Yet the
|
|
safe numerics library detects and traps this behavior as errors. Why
|
|
is that?</a>
|
|
</dt>
|
|
</dl>
|
|
<table border="0" width="100%" summary="Q and A Set">
|
|
<col align="left" width="1%">
|
|
<col>
|
|
<tbody>
|
|
<tr class="question">
|
|
<td align="left" valign="top">
|
|
<a name="idm413202552528"></a><a name="idm413202552272"></a><p><b>1.</b></p>
|
|
</td>
|
|
<td align="left" valign="top"><p>Is this really necessary? If I'm writing the program with the
|
|
requisite care and competence, problems noted in the introduction
|
|
will never arise. Should they arise, they should be fixed "at the
|
|
source" and not with a "band aid" to cover up bad practice.</p></td>
|
|
</tr>
|
|
<tr class="answer">
|
|
<td align="left" valign="top"></td>
|
|
<td align="left" valign="top"><p>This surprised me when it was first raised. But some of the
|
|
feedback I've received makes me thing that it's a widely held view.
|
|
The best answer is to consider the cases in the section <a class="link" href="tutorial.html" title="Tutorial and Motivating Examples">Tutorials and Motivating
|
|
Examples</a>.</p></td>
|
|
</tr>
|
|
<tr class="question">
|
|
<td align="left" valign="top">
|
|
<a name="idm413202549216"></a><a name="idm413202548960"></a><p><b>2.</b></p>
|
|
</td>
|
|
<td align="left" valign="top"><p>Why is Boost.Convert not used?</p></td>
|
|
</tr>
|
|
<tr class="answer">
|
|
<td align="left" valign="top"></td>
|
|
<td align="left" valign="top"><p>I couldn't figure out how to use it from the
|
|
documentation.</p></td>
|
|
</tr>
|
|
<tr class="question">
|
|
<td align="left" valign="top">
|
|
<a name="idm413202547216"></a><a name="idm413202546960"></a><p><b>3.</b></p>
|
|
</td>
|
|
<td align="left" valign="top"><p>Why is the library named "safe ..." rather than something like
|
|
"checked ..." ?</p></td>
|
|
</tr>
|
|
<tr class="answer">
|
|
<td align="left" valign="top"></td>
|
|
<td align="left" valign="top"><p>I used "safe" in large part this is what has been used by
|
|
other similar libraries. Maybe a better word might have been
|
|
"correct" but that would raise similar concerns. I'm not inclined to
|
|
change this. I've tried to make it clear in the documentation what
|
|
the problem that the library addressed is</p></td>
|
|
</tr>
|
|
<tr class="question">
|
|
<td align="left" valign="top">
|
|
<a name="idm413202544848"></a><a name="idm413202544592"></a><p><b>4.</b></p>
|
|
</td>
|
|
<td align="left" valign="top"><p>Given that the library is called "numerics" why is floating
|
|
point arithmetic not addressed?</p></td>
|
|
</tr>
|
|
<tr class="answer">
|
|
<td align="left" valign="top"></td>
|
|
<td align="left" valign="top"><p>Actually, I believe that this can/should be applied to any
|
|
type T which satisfies the type requirement "Numeric" type as
|
|
defined in the documentation. So there should be specializations
|
|
safe<float> et. al. and eventually safe<fixed_decimal>
|
|
etc. But the current version of the library only addresses integer
|
|
types. Hopefully the library will evolve to match the promise
|
|
implied by it's name.</p></td>
|
|
</tr>
|
|
<tr class="question">
|
|
<td align="left" valign="top">
|
|
<a name="idm413202542528"></a><a name="idm413202542272"></a><p><b>5.</b></p>
|
|
</td>
|
|
<td align="left" valign="top"><p>Isn't putting a defensive check just before any potential
|
|
undefined behavior is often considered a bad practice?</p></td>
|
|
</tr>
|
|
<tr class="answer">
|
|
<td align="left" valign="top"></td>
|
|
<td align="left" valign="top"><p>By whom? Is leaving code which can produce incorrect results
|
|
better? Note that the documentation contains references to various
|
|
sources which recommend exactly this approach to mitigate the
|
|
problems created by this C/C++ behavior. See <a class="link" href="bibliography.html#Seacord" title="Secure Coding in C and C++">[<a class="citation" href="bibliography.html#Seacord"><span class="citation">Seacord</span></a>]</a>, <a href="https://www.cert.org" target="_top">Software Engineering Institute - Carnegie
|
|
Mellon University</a></p></td>
|
|
</tr>
|
|
<tr class="question">
|
|
<td align="left" valign="top">
|
|
<a name="idm413202538928"></a><a name="idm413202538672"></a><p><b>6.</b></p>
|
|
</td>
|
|
<td align="left" valign="top"><p>It looks like the implementation presumes two's complement
|
|
arithmetic at the hardware level. So this library is not portable -
|
|
correct? What about other hardware architectures?</p></td>
|
|
</tr>
|
|
<tr class="answer">
|
|
<td align="left" valign="top"></td>
|
|
<td align="left" valign="top"><p>As far as is known as of this writing, the library does not
|
|
presume that the underlying hardware is two's compliment. However,
|
|
this has yet to be verified in a rigorous way.</p></td>
|
|
</tr>
|
|
<tr class="question">
|
|
<td align="left" valign="top">
|
|
<a name="idm413202536592"></a><a name="idm413202536336"></a><p><b>7.</b></p>
|
|
</td>
|
|
<td align="left" valign="top"><p>Why do you specialize numeric_limits for "safe" types? Do you
|
|
need it?</p></td>
|
|
</tr>
|
|
<tr class="answer">
|
|
<td align="left" valign="top"></td>
|
|
<td align="left" valign="top"><p>safe<T> behaves like a "number" just as int does. It has
|
|
max, min, etc Any code which uses numeric limits to test a type T
|
|
should works with safe<T>. safe<T> is a drop-in
|
|
replacement for T so it has to implement all the operations.</p></td>
|
|
</tr>
|
|
<tr class="question">
|
|
<td align="left" valign="top">
|
|
<a name="idm413202534224"></a><a name="idm413202533968"></a><p><b>8.</b></p>
|
|
</td>
|
|
<td align="left" valign="top"><p>According to C/C++ standards, unsigned integers cannot
|
|
overflow - they are modular integers which "warp around". Yet the
|
|
safe numerics library detects and traps this behavior as errors. Why
|
|
is that?</p></td>
|
|
</tr>
|
|
<tr class="answer">
|
|
<td align="left" valign="top"></td>
|
|
<td align="left" valign="top"><p>The guiding purpose of the library is to trap incorrect
|
|
arithmetic behavior - not just undefined behavior. Although a savvy
|
|
user may understand and keep present in his mind that an unsigned
|
|
integer is really modular type, the plain reading of an arithmetic
|
|
expression conveys the idea that all operands are plain integers.
|
|
Also in many cases, unsigned integers are used in cases where
|
|
modular arithmetic is not intended, such as array indexes. Finally,
|
|
the modulus for such an integer would vary depending upon the
|
|
machine architecture. For these reasons, in the context of this
|
|
library, an unsigned integer is considered to a representation of a
|
|
subset of integers which is expected to provide correct integer
|
|
results. Note that this decision is consistent with INT30-C, “Ensure
|
|
that unsigned integer operations do not wrap” in the CERT C Secure
|
|
Coding Standard [Seacord 2008]..</p></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr>
|
|
<td align="left"></td>
|
|
<td align="right"><div class="copyright-footer">Copyright © 2012 Robert Ramey<p><a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">Subject to Boost
|
|
Software License</a></p>
|
|
</div></td>
|
|
</tr></table>
|
|
<hr>
|
|
<div class="spirit-nav">
|
|
<a accesskey="p" href="performance_tests.html"><img src="images/prev.png" alt="Prev"></a><a accesskey="u" href="index.html"><img src="images/up.png" alt="Up"></a><a accesskey="h" href="index.html"><img src="images/home.png" alt="Home"></a><a accesskey="n" href="pending_issues.html"><img src="images/next.png" alt="Next"></a>
|
|
</div>
|
|
</body>
|
|
</html>
|