false positives for products of primes larger than 2^16. For example,
before this commit:
$ /usr/games/primes 4295360521 4295360522
4295360521
but
$ /usr/games/factor 4295360521
4295360521: 65539 65539
or
$ /usr/games/primes 3825123056546413049 3825123056546413050
3825123056546413049
yet
$ /usr/games/factor 3825123056546413049
3825123056546413049: 165479 23115459100831
or
$ /usr/games/primes 18446744073709551577
18446744073709551577
although
$ /usr/games/factor 18446744073709551577
18446744073709551577: 139646831 132095686967
Incidentally, the above examples show the smallest and largest cases that
were erroneously stated as prime in the range 2^32 .. 3825123056546413049
.. 2^64; the primes(6) program now stops at 3825123056546413050 as
primality tests on larger integers would be by brute force factorization.
In addition, special to the NetBSD version:
. for -d option, skip first difference when start is >65537 as it is incorrect
. corrected usage to mention both the existing -d as well as the new -h option
For original FreeBSD commit message by Colin Percival, see:
http://svnweb.freebsd.org/base?view=revision&revision=272166
by reference, and changes the value behind the pointer under some
circumstances (basically if it finds more than 2 different factors).
It also calls itself if it finds a factor which is not considered prime
(by openssl's miller-rabin check) and uses the call argument afterwards.
This doesn't work -- we need to copy the argument into its own storage.
-Modify the code to do the "rho" algorithm as was initially announced.
It takes somewhat longer in rare cases, but still works in cases where
the "p-1" algorithm is unusable. This might fix PR misc/43192
by Luiz Henrique de Figueiredo.
-Add some optional debug support, minor cleanup.
could be overrun if its last entry (65537) was a factor of the input
(this does not affect PR misc/43192 -- the factors are much larger
here: 7742394596501*159455563099482401)
algorithm; fixes "factor 2147483647111311". Correct comment;
algorithm is Pollard p-1, not Pollard rho. Increase base if p-1
algorithm reaches 1; fixes "factor 99999999999991". Testcases from
David A Bagley <bagleyd@tux.org>.
was prime to still called the Pollard Rho function when it didn't have
to. Problem report by Nathan Williams.
Unfortunately this one can't be picked up by a simple regression test
since the broken way still produced the correct output, but just took
far longer...
This merges in all such remaining changes from the Linux port of the
NetBSD games, except in hunt (where substantial changes from OpenBSD
need to be looked at).
Some such changes were previously covered in PRs bin/6041, bin/6146,
bin/6148, bin/6150, bin/6151, bin/6580, bin/6660, bin/7993, bin/7994,
bin/8039, bin/8057 and bin/8093.
christos