Hi Bruno,
thanks for replying so quickly.
Let's assume I have a procedure
void *foo_create (size_t n)
{
void *foo = malloc (a + n * b);
if (foo == NULL) ...;
...
return foo;
}
I want 'foo_create' to handle possible overflows. To me, it seems that
should use the xsize module for this and to replace 'a + n * b' accordingly
because I have no easy local control over "-ftrapv". This seems to force,
however, that the 'n' parameter of the 'foo_create' has to be a size_t and
not an idx_t. Unless I want possibly unsafe casts in my program, this
forces the code interacting with 'foo_create' to use 'size_t' instead of
'idx_t' as well, which somewhat seems to forfeit the advantages of 'idx_t'.
That's why I am wondering whether it makes sense to have an xsize module
that uses idx_t instead of size_t.
PS Another question related to idx_t: Often I code something like:
void f (size_t n, size_t i)
{
assure (i < n);
...
}
Now if I replaced unsigned by signed ints, I guess I should write
void f (idx_t n, idx_t i)
{
assure (i < n);
assure (0 <= i);
...
}
But this makes the code more complicated... :(
Am Mi., 7. Apr. 2021 um 11:51 Uhr schrieb Bruno Haible <br...@clisp.org>:
> Hi Marc,
>
> > What is the relationship between these two modules? Both try to minimize
> > subtle bugs due to overflow.
>
> These two modules, and the wraparound/overflow checking macros of
> 'intprops'
> [1], are attempts to catch integer overflow.
>
> The three approaches differ in terms of coding effort and percentage
> of overflows that get caught.
>
> With 'idx', you use signed integers, and rely on compiler options such as
> 'gcc -ftrapv' or 'gcc -fsanitize=undefined' to report overflows.
> - Coding effort: small.
> - Overflows caught: all.
>
> With 'xsize', you use unsigned integers (size_t), and do a single overflow
> check at the end of the computation; this check is implicit if you call
> malloc, as malloc (SIZE_MAX) will always fail.
> - Coding effort: medium.
> - Overflows caught: those with explicit checks.
>
> With 'intprops', you use signed or unsigned integers, and do an overflow
> check at each step of the computation.
> - Coding effort: high.
> - Overflows caught: those with explicit checks.
>
> > However, both approaches cannot be easily combined as xsize expects
> > unsigned integers while idx is a signed one.
>
> You don't need combine the three approaches for the same computation.
> For each computation, pick the approach you prefer.
>
> > What is the suggested use of these modules for new code?
>
> IMO, there's no definite answer to this question. All three approaches are,
> in some way, experimental. At least as long as not all distros are
> compiling with 'gcc -ftrapv' systematically.
>
> Paul, how do you see this?
>
> (I'm thinking of adding the answers to the documentation.)
>
> Bruno
>
> [1]
> https://www.gnu.org/software/gnulib/manual/html_node/Wraparound-Arithmetic.html
>
>
