This is an experiment with a handful of macros for writing the
checks, most of which are compile-time:
MUL_OK(t, a, b) Does a*b avoid overflow in type t?
ADD_OK(t, a, b) Does a + b avoid overflow in type t?
TOOMANY(t, x, b, m) Are there more than m b-element blocks in x in type t?
(I.e., does ceiling(x/b) > m?)
Addenda that might make sense but are not needed here:
MUL(t, a, b, &p) Set p = a*b and return 0, or return ERANGE if overflow.
ADD(t, a, b, &s) Set s = a+b and return 0, or return ERANGE if overflow.
Example:
uint32_t a = ..., b = ..., y = ..., z = ..., x, w;
/* input validation */
error = MUL(size_t, a, b, &x);
if (error)
fail;
if (TOOMANY(uint32_t, x, BLKSIZ, MAX_NBLK))
fail;
y = HOWMANY(x, BLKSIZ);
if (z > Z_MAX)
fail;
...
/* internal computation */
__CTASSERT(MUL_OK(uint32_t, Z_MAX, MAX_NBLK));
w = z*y;
Obvious shortcomings:
1. Nothing checks your ctassert matches your subsequent arithmetic.
(Maybe we could have BOUNDED_MUL(t, x, xmax, y, ymax) with a
ctassert inside.)
2. Nothing flows the bounds needed by the arithmetic you use back
into candidate definitions of X_MAX/Y_MAX.
But at least the reviewer's job is only to make sure that (a) the
MUL_OK matches the *, and (b) the bounds in the assertion match the
bounds on the inputs -- in particular, the reviewer need not derive
the bounds from the context, only confirm they are supported by the
paths to it.
This is not meant to be a general-purpose proof assistant, or even a
special-purpose one like gfverif <http://gfverif.cryptojedi.org/>.
Rather, it is an experiment in adding a modicum of compile-time
verification with a simple C API change.
This also is not intended to serve as trapping arithmetic on
overflow. The goal here is to enable writing the program with
explicit checks on input and compile-time annotations on computation
to gain confident that overflow won't happen in the computation.
Sprinkle a few more assertions to help along the way.
(Actually, it was justified; I just hadn't made explicit the relation
to the value of fdpos that all two callers specify.)
Defer seeking the *input* image, or winding it forward, until we are
certain we all ready in the cloop2 output, because when the input
image is a pipe, we don't get a chance to seek back to the beginning
and start from the top instead of restarting.
If restart does fail, don't try to seek the input image back to the
beginning unless we had already tried to seek or wind it forward.
Add some automatic tests for this and related cases.
XXX pullup to netbsd-7, netbsd-6
For vnduncompress on nonseekable input, the window size is as large
as it needs to be by default, as before. Not clear that this is the
right choice -- by default vnduncompress on nonseekable input will
just use unbounded memory unsolicited.
Perhaps vndcompress and vnduncompress ought by default to choose a
limited window size (say, 8192 entries, i.e. 64k bytes, the default
MAXPHYS), and vnduncompress should fall back to an unlimited window
only if the input is nonseekable.
Makes more sense and makes it consistent with other utilities such as
pax and pigz. This vndcompress has never gone out in a release, so
changing the name of the option shouldn't cause too many problems...
