On Fri, 2018-07-13 at 10:08 +0200, Niels Möller wrote:
>
> I've had a closer look now, and I think both are of similar type. In
> eratosthenes.c, we have a bitmap initialized with
>
> static void
> vector_init(unsigned long *vector, unsigned long size)
> {
> unsigned long end = (size + BITS_PER_LONG - 1) / BITS_PER_LONG;
> unsigned long i;
>
> for (i = 0; i < end; i++)
> vector[i] = ~0UL;
> }
>
> and later updated with the loop
>
> static void
> vector_clear_bits (unsigned long *vector, unsigned long step,
> unsigned long start, unsigned long size)
> {
> unsigned long bit;
>
> for (bit = start; bit < size; bit += step)
> {
> unsigned long i = bit / BITS_PER_LONG;
> unsigned long mask = 1L << (bit % BITS_PER_LONG);
>
> vector[i] &= ~mask;
> }
> }
>
> The value of the size argument is the same in both places (named
> "sieve_nbits" in the calling code). The static analyzer complains
> that
> vector[i] is not properly initialized. And it's kind-of right: In
> case
> (size + BITS_PER_LONG - 1) wraps around, the bitmap will not be
> initialized properly. But I would classify it as an out-of-bounds
> access, not use of uninitialized data.
>
> I could add an overflow check in the vector_alloc function, which
> uses
> the same expression, and where it might make sense. I wonder of that
> would make the analyzer happy.
>
> In eccdata.c, the allocation function is ecc_alloc, which alllocates
> an
> array and loops over it to initialize all elements. The complant is
> in
> ecc_pippenger_precompute, which allocates an array with
>
> ecc->table = ecc_alloc (ecc->table_size);
>
> and the complaint is the assignment of element 1,
>
> ecc_set (&ecc->table[1], &ecc->g);
>
> where ecc->table[1].x->_mp_alloc is claimed to be uninitialized.
>
> This also is kind-of right; if the program is run with strange
> parameters, we might get ecc->table_size < 2 (and again, in that
> case,
> it's an out of bounds access).
>
> I don't have that much experience with the static analyzer. Should I
> just add error handling for the corner cases, and see if that solves
> the problem?
An assert() should be sufficient to inform it of the constraints.
regards,
Nikos
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
