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

Previous Next

Full log

View this message in rfc822 format

From: Torbjörn Granlund <tg <at> gmplib.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 78476 <at> debbugs.gnu.org
Subject: bug#78476: GNU 'factor' problems with 128-bit word
Date: Tue, 20 May 2025 00:23:50 +0200

Paul Eggert <eggert <at> cs.ucla.edu> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.