What happened to the profile?

Dirk Hohndel dirk at hohndel.org
Mon Oct 7 11:45:44 UTC 2013


On Mon, 2013-10-07 at 11:26 -0700, Linus Torvalds wrote:
> On Mon, Oct 7, 2013 at 10:59 AM, Thiago Macieira <thiago at macieira.org> wrote:
> >
> > There's a private API that avoids memory allocation:
> >
> > Q_CORE_EXPORT double qstrtod(const char *s00, char const **se, bool *ok);
> 
> Looking at the source code for qstrtod(), it looks like it does the
> right thing. You can also see how hard it is to actually do it with
> proper rounding to the least significant bit. It's about 1700 lines of
> code (with comments), much of it accessing the floating point values
> directly using integer arithmetic. This comment snippet says a lot:
> 
>  * Inspired loosely by William D. Clinger's paper "How to Read Floating
>  * Point Numbers Accurately" [Proc. ACM SIGPLAN '90, pp. 92-101].
> 
> The Qt code has also clearly been taken from some old BSD source
> (looks like NetBSD). It has support for VAX floating point issues etc,
> and uses two separate "long" variables each containing up to nine
> digits, instead of using an "u64" for up to 18 digits. It has a RCS ID
> of 1998, but realistically I suspect the code goes back even further.

Awesome. This sounds like EXACTLY the code we need.
Maybe not.

> So I think the Qt function works, but that thing is declared to be
> internal. I think my simple function is perfectly sufficient. I
> suspect that in practice, my simple stupid version could be made to be
> good to the last bit by simply using "long double" and doing all the
> internal calculations in 80-bit FP (on x86). But for our XML parsing
> needs, we really don't need it.

Your code is fine once I fixed the obvious bugs (snicker)...

(you assume that the second parameter is != NULL which isn't valid...
Subsurface calls ascii_strtod with NULL as second parameter when it
doesn't need to know where parsing ended...)

/D




More information about the subsurface mailing list