Nikos Mavrogiannopoulos <n...@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/2018-07-12-205643-1877-1/index.html (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 -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
