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
