Prior to this commit, primes(6) relied solely on sieving with primes up
to 65537, with the effect that composite numbers which are the product
of two non-16-bit primes would be incorrectly identified as prime. For
example,
# primes 1099511627800 1099511627820
would output
1099511627803
1099511627807
1099511627813
when in fact only the first of those values is prime.
This commit adds strong pseudoprime tests to validate the candidates
which pass the initial sieving stage, using bases of 2, 3, 5, 7, 11,
13, 17, 19, and 23. Thanks to papers from C. Pomerance, J.L. Selfridge,
and S.S. Wagstaff, Jr.; G. Jaeschke; and Y. Jiang and Y. Deng, we know
that the smallest value which passes these tests is 3825123056546413051.
At present we do not know how many strong pseudoprime tests are required
to prove primality for values larger than 3825123056546413050, so we
force primes(6) to stop at that point.
Reviewed by: jmg
Relnotes: primes(6) now correctly enumerates primes up to
3825123056546413050
MFC after: 7 days
Sponsored by: EuroBSDCon devsummit
Check if large factor is prime before applying Pollard's algorithm;
fixes "factor 2147483647111311". Increase base if p-1 algorithm
reaches 1; fixes "factor 99999999999991".
Testcases from David A Bagley <bagleyd@tux.org>.
Fixes from Joseph Myers <jsm@NetBSD.org>.
Problem rediscovered by an attempt to factor my phone number.
A few other incidental fixes: correct a couple of factually incorrect
comments; use ident string macros; move from 4-clause to 3-clause
BSD licence (University of California copyright).
Obtained from: NetBSD
from NetBSD, altered to retain the FreeBSD -h feature and various
stylistic improvements and avoid regressions. In the absence of
OpenSSL (and therefore bignums) the old code is used.
PR: 43831
Reviewed by: kris, markm, obrien
Obtained from: NetBSD
MFC after: 2 weeks
Use '0' for base rather than 10 to allow for more flexible input bases.
Inspired by changes in PR 7402, but mostly redone by me to get past
bde filter.
Submitted by: Timo J. Rinne
PR: 7402
EOF? The getopt(3) manpage clearly states that the return value is *-1*,
not EOF! Besides, getopt(3) isn't reading from a file. :)
Noticed-while: merging to 2.2 (where this is correct).
of the x11 based games. I'm not going to tag the originals with bsd_44_lite
and do this in two stages since it's just not worth it for this collection,
and I've got directory renames to deal with that way. Bleah.
Submitted by: jkh