Date: Sun, 28 Sep 2014 10:30:39 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Sean Bruno <sbruno@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r272210 - head/games/factor Message-ID: <20140928101352.C927@besplex.bde.org> In-Reply-To: <201409271057.s8RAvYdF086338@svn.freebsd.org> References: <201409271057.s8RAvYdF086338@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140928101352.C927>