Ciao,
Il 2022-10-26 13:40 ni...@lysator.liu.se ha scritto:
jy l writes:
It seems like in `mpz_nextprime` this line (
https://gmplib.org/repo/gmp/file/tip/mpz/nextprime.c#l204), when `n`
is
very large, it doesn't restrict the value of `odds_in_composite_sieve`
which leads to the `alloca` below crash and might cause more buffer
You are right.
Thank you very much for the report.
I agree the array size odds_in_composite_sieve should have an upper
bound here (and if we expect a very large sieve to be useful, it should
be allocated with TMP_ALLOC_TYPE, which falls back to heap allocation
for large sizes).
I'd like to have the time to rewrite that part of the code, but I
actually don't.
I agree, we probably don't really need a very large array, and the code
should work with any size. But the author of the code proposed the
5*nbits size, and this size can be used...
I then just applied a patch following your suggestion: use ALLOC instead
of SALLOC.
I'm afraid I don't understand the comment
/* Corresponds to a merit 14 prime_gap, which is rare. */
odds_in_composite_sieve = 5 * nbits;
The author of the code was working on large prime gaps (large sequences
of composites between two primes). The "merit" is some kind of measure
of how much unlikely the size of a prime gap is, so that the likeliness
of a gap of 1000 numbers between primes with 1000 digits can be compared
with the likeliness of a gap of 900 numbers only, but with much smaller
primes. But I do not know the details. I'm sure that one can find them
on mersenneforum :-) and I assume that also a shorter array should work
very well :-D
Ĝis,
m
--
http://bodrato.it/papers/
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
