svn commit: r272210 - head/games/factor

[Bruce Evans]

On Sat, 27 Sep 2014, Sean Bruno wrote:

> Log:
>  Update factor for changes to types in primes, which is a dependency.
>
>  Fixes build-fail on mips32 introduced at 272207.
>
> Modified:
>  head/games/factor/factor.c
>
> Modified: head/games/factor/factor.c
> ==============================================================================
> --- head/games/factor/factor.c	Sat Sep 27 09:57:34 2014	(r272209)
> +++ head/games/factor/factor.c	Sat Sep 27 10:57:34 2014	(r272210)
> @@ -69,6 +69,7 @@ __FBSDID("$FreeBSD$");
> #include <ctype.h>
> #include <err.h>
> #include <errno.h>
> +#include <inttypes.h>

Needed only for the style bugs below.

> #include <limits.h>
> #include <stdio.h>
> #include <stdlib.h>
> @@ -227,7 +228,7 @@ pr_fact(BIGNUM *val)
>
> 		/* Divide factor out until none are left. */
> 		do {
> -			printf(hflag ? " 0x%lx" : " %lu", *fact);
> +			printf(hflag ? " 0x%" PRIx64 "" : " %" PRIu64 "", *fact);

This has the same PRI* ugliness as primes.c, but doesn't break the output
format for the hex case (it still has the "0x" prefix).

> 			BN_div_word(val, (BN_ULONG)*fact);
> 		} while (BN_mod_word(val, (BN_ULONG)*fact) == 0);

However, it seems to need much larger changes to keep up.  Its BN and
BIGNUMS aren't actually (arbitrary-precision) bignums.  BIGNUM is just
ubig, which is now uint64_t.  BN_ULONG is still just u_long.  Parsing
functions still use just strtoul() to create BIGNUMs.  Now they can't
even create the non-bignums given by BIGNUM == ubig on 32-bit systems.

So if there are no other bugs, factor(6) is probably limited to
UINT32_MAX on 32-bit system and to the new limit SIEVE_MAX on 64-bit
systems (like the previous version of primes(6)).  Its documentation
doesn't seem to have been changed.  Its old documentation gives the
wrong limit of UINT64_MAX (expressed unreadably in decimal) on 64-bit
systems.

Bruce