Nikos Mavrogiannopoulos nmav@redhat.com writes:
It seems that static analyzer in F28 finds few issues: https://gitlab.com/gnutls/nettle/-/jobs/81332560 (click on browse for artifacts)
They are mem leaks on examples and one which relates to gmp-mini.
I fixed the leaks. Remaining issues listed on https://gnutls.gitlab.io/-/nettle/-/jobs/81425078/artifacts/scan-build-lib/2... (but will disappear in a few days; should we increase the expire_in parameter in .gitlab-cy.yml?)..
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?
Regards, /Niels