GNU bug report logs -
#78476
GNU 'factor' problems with 128-bit word
Previous Next
Full log
Message #11 received at 78476 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-18 02:07, Torbjörn Granlund wrote:
> I don't think is makes much sense to handle two 128-bit words in this
> code. In fact, the use of uintmax_t was a mistake, it should use
> "unsigned long" or "unsigned long long" whichever is efficiently
> supported directly by the hardware.
Fine, but the 128-bit bug is independent of uintmax_t. Suppose we change
factor.c to never use uintmax_t, and suppose we have a (theoretical but
allowed) platform where unsigned long is 128 bits and where factor.c
uses that type for its words. Then before my Saturday coreutils
commit[1], this code in prime_p:
/* We have already cast out small primes. */
if (n < (wide_uint) FIRST_OMITTED_PRIME * FIRST_OMITTED_PRIME)
return true;
was incorrect. The problem is that when given 2**128 - 101,
factor_using_pollard_rho generates 155 and tests it with prime_p, and
the above code causes prime_p to incorrectly report that 155 is prime.
> While uintmax_t could be made to work also for the cases you report, it
> will be inefficient.
>
> A few months ago, I contributed a suggested new core factoring function
> to GNU coreutils, which is, IIRC, 2-3 times faster than the current code
> for the bignum range. It uses GMP's mpn functions with "Montgomery
> multiplication".
>
> There were two problems with my new core code:
>
> 1. It will not work with mini-GMP, which I think is undesiable.
>
> 2. It did not optimise for smaller factoring tasks. The fix for this
> would be to merge that from the current coreutils factor.c.
Thanks, I didn't know about all that. I plan to take a look at it.
[1]:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=fe51b33859d2e7286425d6d5600288ce9ae43bd1
This bug report was last modified 22 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.