WHATWG on 2024-03-12

03:42	<sideshowbarker>	Is the https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values algorithm known to differ in any way from the behavior of `strtod`?
10:38	<Ms2ger>	I assume you could find any number of differences if you looked, if those are even consistent between platforms
10:51	<sideshowbarker>	Well the thing is, as far as I can see, in practice none of Blink, Gecko, Servo, or WebKit actually implement that algorithm — at least not intentionally. Instead, as far as I can see, Blink and Gecko use https://github.com/google/double-conversion — and until a year ago, WebKit did too. WebKit now uses https://github.com/fastfloat/fast_float — which is functionally equivalent to `strtod` — as a drop-in replacement for the double-conversion it had also been using previously. So if our goal is interoperability, it seems like what we’d ideally need to specify is, functional equivalence with double-conversion — which essentially seems to mean functional equivalence with `strtod`.
10:52	<sideshowbarker>	And for the case of Servo, as far as I can see, it just uses the Rust standard library’s `parse()`
10:53	<sideshowbarker>	The only engine implementation I have found that seems to attempt to implement its own double parser is the one in Ladybird.
10:55	<sideshowbarker>	But by attempting implement what’s in the spec rather than just using double-conversion or fast_float, it seems like the Ladybird implementation risks lack of interoperability with the other engines.
11:58	<Ms2ger>	Oh, hmm. I seem to recall that all the integer ones were handcrafted, at least; but maybe floats are too hard
14:26	<akaster>	I suspect Ladybird will have quite a few Interop concerns like that, seeing as implementing the spec as written before trying to optimize is a project goal/strategy. And that pulling in a third party dependency would be against the project's... Identity? Ethos? Something like that. If the status quo is that everyone uses an implementation that "matches strtod" then perhaps the spec should have a normative reference to ISO C rather than define the float parsing algorithm itself.
15:14	<annevk>	Hmm, has anyone actually identified any differences? Also, it's unclear to me if ISO C is a suitable reference. I thought most ISO standards were not freely accessible.
16:12	<Jeffrey Yasskin>	Both (the specification of) strtod and HTML start with a computation of the exact mathematical value of the number, and then round to a nearby representation. strtod's rounding is: " If the subject sequence has the decimal form and at most DECIMAL_DIG (defined in <float.h>) significant digits, the result should be correctly rounded. If the subject sequence D has the decimal form and more than DECIMAL_DIG significant digits, consider the two bounding, adjacent decimal strings L and U, both having DECIMAL_DIG significant digits, such that the values of L, D, and U satisfy L ≤ D ≤ U. The result should be one of the (equal or adjacent) values that would be obtained by correctly rounding L and U according to the current rounding direction, with the extra stipulation that the error with respect to D should have a correct sign for the current rounding direction." This is also a "should"-level requirement, while HTML's is a "must". So there's not just one "strtod"; potentially each platform can have its own. Looking at `fast_float()`, they say "We provide exact rounding (including round to even).", which I think matches HTML's requirement.
22:12	<Jeffrey Yasskin>	FYI, https://whatwg.org/working-mode links to https://whatwg.org/Stages.md, which doesn't exist.
22:13	<Jeffrey Yasskin>	(I'll file an issue at some point, but distracted by the W3C Breakout Day right now.)