Reporting a gmp bug

[Marco Bodrato]

Ciao,

Il 2022-10-26 13:40 nisse at lysator.liu.se ha scritto:
> jy l <linjy0410 at gmail.com> 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/