[libcxx-commits] [PATCH] D70631: Microsoft's floating-point to_chars powered by Ryu and Ryu Printf

[Stephan T. Lavavej via Phabricator via libcxx-commits]

STL_MSFT added a comment.

> Certainly, we could use the test cases.

Test cases beyond the 5 MB here are very welcome.

Aside from superficial bugs which I was easily able to fix (like printing `"4."`) and a bug that I found in Ulf's earliest Ryu Printf code which he fixed promptly, I have been unable to find any bugs in either Ryu or Ryu Printf despite months of intensive testing. The test suite in this review, which is derived from Ulf's, contains hardcoded test cases exercising all of the tricky scenarios that I'm aware of. It also contains randomized coverage, verifying that scientific shortest (i.e. Ryu) round-trips, although it doesn't directly verify the shortest property. (That should now be possible, as I have an explicit list of anomalous powers of 2 thanks to Rick Regan's Exploring Binary blog; those powers are tested.) The randomized coverage also compares fixed shortest integers (i.e. Ryu with a long division or Ryu Printf fallback) against sprintf(), verifying that all digits are printed correctly. Those are in test_floating_prefix(). In test_floating_precision_prefix(), randomized coverage verifies that fixed, scientific, and general precision emit the same output as printf(). (This doesn't test rounding, primarily because Microsoft's UCRT contained a rounding bug that Ryu Printf is immune to, but the hardcoded test cases carefully verify rounding.) Finally, during my original testing, I took the randomized round-tripping code and modified it to run tests in parallel, forever, and validated trillions of values on a many-core machine for days, with zero failures. Upstream, Ulf's readme explains how he exhaustively checked all 32-bit floats for shortest round-trip (validating both properties).

The code that's most likely to be incorrect is the code that I've layered on top of Ryu and Ryu Printf; e.g. the `_Can_use_ryu` switching criterion is something that I had to derive from first principles, and similarly for the general precision code that avoids trial formatting with a "triangular table" and then formats into a local buffer before trimming zeroes. That said, I wrote all of that code with maximum attention to detail, and I believe I got it right (verified by tests).

Aside from randomized testing directly verifying the shortest property, I believe that the other interesting area for testing would be fuzz testing; I experimented a bit with this (finding no issues).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70631/new/

https://reviews.llvm.org/D70631