[libc-commits] [PATCH] D157535: [libc] Fix printf %f bugs

[Michael Jones via Phabricator via libc-commits]

michaelrj added inline comments.


================
Comment at: libc/test/src/stdio/sprintf_test.cpp:1297
+  // The number continues after the literal because floating point numbers don't
+  // represent a specific value, but a range of values. The number provided as
+  // the literal and the number printed are both in the range for the value
----------------
sivachandra wrote:
> I am confused with this wording. My knowledge says that if you write down a literal, then is already an exact value (of course, might not correspond exactly to an encoded value). Likewise, if a floating number is encoded as single/double/quad precision number, then that is also an exact number.
The literal you write down maps to a value, but it's usually not exact. As an example, when you write `0.1` the "actual" value as a double is `0.1000000000000000055511151231257827021181583404541015625`. That's the value you get if you actually calculate `1.mantissa * 2^exponent`, but when converting to and from a string that's not the only valid value. The number only has ~17 significant figures, so if you change the digits after that point you'll still get the same result. In this case the first non-significant digit happens to be the first `5`. You can set that digit and any digits after to any value you want and it'll still give you the same result. As long as you stay within that range (0.1000...000, 0.1000...001), the number is equivalent. That's what I meant by floating point numbers representing a range.


================
Comment at: libc/test/src/stdio/sprintf_test.cpp:1303
+      "000000000000000000000000000000000000000000000000000000000000000000000001"
+      "131959884853339045938639911360973972585316399767392273697826861241937664"
+      "824105639342441431495119762431744054912109728706985341609159156917030486"
----------------
sivachandra wrote:
> sivachandra wrote:
> > Nit: Add a comment explaining why there are digits beyond the `3339` even though the literal above does not.
> Isn't the reason that the closest number that can be represented as a double precision number to that literal?
This is a simpler way to explain it. I've adjusted the comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157535