bug#78476: GNU 'factor' problems with 128-bit word

Paul Eggert <[email protected]> writes:

  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.

Why is it incorrect?

I read you change, and I strongly disgree with it.

I actually find it extremely worrying that a change is motivated by "We
don't know why the code misbehaves when wide_uint is wider;" and then
the presumed bug is masked with a pretty questionable change.  Really?

How about debugging it?

Furthernorem tinkering with mature code for porting it to something with
does not exist and likely will never exist, is a bad idea.

No, we are very unlikely to see systems with 128x128->256 bit hardware
multiply support, which is the only case where forcing factor.c to do
128-bit arithmetic.

Let's use our time and effort on improving things for the word we live
in.

-- 
Torbjörn
Please encrypt, key id 0xC8601622