gmp_printf bug?

[Vincent Lefevre]

On 2011-07-21 12:57:51 +0200, Torbjorn Granlund wrote:
> (2) Stay with the 'double' approximation but cope with its poor accuracy
> for large mpf exponents.  This would require a rewrite of (at least)
> mpf/get_str.c, making it iterate in the code that generates a suitable
> integer for passing to mpn_get_str.  (In practice, we would only make
> one iteration for normal exponents, and two iterations for tiny/huge
> exponents.)

One problem with 'double' is that the real precision can be set to
single precision on processors with dynamic precision (x86). This
should be forbidden, but unfortunately occurs in practice, and it
would be annoying if this introduced a security problem. For instance
there was a vulnerability (buffer overflow) in the Firefox JavaScript
engine a few years ago due to some plugin that switches the x87 FPU
configuration to single precision.

> I am not sure how to compute the more-than 53 bits accurate logarithm
> tables needed for solution 1, in the very constrained environment of a
> GMP compile.  I see two solutions: (a) put 64-bit logarithms for all
> bases in a master table, and truncate these as needed during compilation
> and (b) teach the dumbmp.c bootstrap library to compute base-2
> logarithms.  Such computations need not be efficient at all, but it
> still seems tricky.

Since performance for base-2 logarithms doesn't matter, they could
be computed with a simple shift-and-add algorithm. I suppose that
this could be done entirely with integers.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)