Hi Marc, > > The problem with the glibc code is that they have specialized code for each > > format: > > - IEEE 754 single-precision, > > - IEEE 754 double-precision, > > - 'long double' with LDBL_MANT_DIG == 106 (a.k.a. "double double"), > > - 'long double' with LDBL_MANT_DIG == 113 (a.k.a. "quad precision"). > > That makes for a lot of code and a lot of required testing, and is not > > future-proof (regarding new floating-point types). > > > > > If possible, in Gnulib, we would prefer a single implementation, even if > > it is a bit slow. > > > > I am not sure whether it makes sense to implement a more generic > algorithm. When the mantissa width is known (and the range of denormalized > numbers), the algorithms can avoid big integer arithmetic most of the > time.
It is OK to have optimizations for specific *_MANT_DIG values. But the algorithm should be formulated in such a way that it works for other, yet unknown, *_MANT_DIG values as well. Otherwise it's not future-proof. > A generic algorithm that does not check special cases would probably > use big integers in all code paths and could give no upper bound of memory > usage. That's acceptable. > If one is willing to include GNU MPFR, a correct generic > implementation seems to be already readily available by combining > mpfr_strtofr and, say, mpfr_get_d. Packages that use Gnulib would generally not like to have additional installation dependencies (GMP and MPFR); therefore this approach is a non-starter. But it would be OK to pull a few source files from MPFR and combine them with mini-gmp — assuming that this does not lead to a maintenance hassle. > If reusing the glibc code is not too complicated so that procedures like > (c_)strtoaf, (c_)strtoad, and (c_)strtoald can be provided, it is better > than nothing. As I said in the previous mail: If you organize things in such a way that we have 4 different implementations of the routines, and no way of handling unknown values of *_MANT_DIG, then it's not better than what we have now, IMO. Bruno
