Re: [musl] Do you recommend using fmt_fp() and

[Rich Felker <dalias@libc.org>]

On Tue, Aug 23, 2022 at 07:00:41PM +0200, ardi wrote:
> On Fri, Aug 19, 2022 at 5:19 AM Rich Felker <dalias@libc.org> wrote:
> >
> > On Thu, Aug 18, 2022 at 05:51:26PM +0200, ardi wrote:
> > > Hi,
> > >
> > > I'm looking for a small and robust dtoa-like implementation for quad
> > > floats (IEEE binary128)  [...]
> > >
> > I think the fmt_fp code is a very good choice for this. It's basically
> > the minimal, dependency-free, most straightforward way of doing
> > exact/correctly-rounded binary floating point to decimal conversion,
> > and it doess not depend in any way on the format of the long double
> > type, just knowing the parameters (MANT_DIG, MAX_EXP), and being able
> > to do a very minimal amount of math on the floating point type to
> > extract the mantissa and to determine rounding behavior to match the
> > floating point type's.
> >
> > If you don't have the equivalent of frexpl you can even do that part
> > with portable arithmetic on the floating point type. At one point long
> > ago I think I even had a version of the code that did that, but it
> > doesn't seem to have ever been in musl proper. It probably predated
> > musl.
> >
> > The same should apply to the floatscan.c code if you need the other
> > direction conversion too. It's just a direct dependency-free version
> > of the minimal bignum logic needed to do it.
> 
> Thanks a lot. I'm working on adapting it at the moment!
> 
> One question, though, because I don't know the musl internals, and
> I'm defining a custom FILE struct that has only the fields used by
> the shgetc.c source file: Can the __uflow() invocation at line 23
> of shgetc.c be called for string pseudo-FILEs, or is it guaranteed that
> it will be called for real FILE objects only?
> 
> I ask the question because __uflow() drives into the stdio internals,
> and I'd prefer to avoid that (I'm implementing the fp<>string code
> for strings only).
> 
> Kind regards and thanks a lot!

See how strtod.c uses sh_fromstring and how sh_fromstring does not
define any io callbacks (so that calling __uflow would necessarily
result in a call to a null or ununitialized function pointer). From
that, it's clear that it must not be reachable (or the existing code
in musl would be broken).

Rich