forked from mpaland/printf
-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exceeding representation range and spewing junk for extremal powers #114
Labels
bug
Something isn't working
resolved-on-develop
A changeset fixing this issue has been commiutted to the development branch
Comments
eyalroz
added a commit
that referenced
this issue
Feb 5, 2022
* Special-casing the power-of-10 function for 10^308 and 10^-308. * Special-casing `get_normalized_components()` to not strive for better precision for near-extremal powers and settle for the "rougher" way to obtain the integral and decimal parts. * Added a test-case of a near-extremal-power which fails due to the re-normalization even if the powering is correct.
eyalroz
added a commit
that referenced
this issue
Feb 5, 2022
* Special-casing the power-of-10 function for 10^308 and 10^-308. * Special-casing `get_normalized_components()` to not strive for better precision for near-extremal powers and settle for the "rougher" way to obtain the integral and decimal parts. * Added a test-case of a near-extremal-power which fails due to the re-normalization even if the powering is correct.
eyalroz
added a commit
that referenced
this issue
Feb 6, 2022
* Special-casing the power-of-10 function for 10^308 and 10^-308. * Special-casing `get_normalized_components()` to not strive for better precision for near-extremal powers and settle for the "rougher" way to obtain the integral and decimal parts. * Added a test-case of a near-extremal-power which fails due to the re-normalization even if the powering is correct.
eyalroz
added a commit
that referenced
this issue
Feb 7, 2022
…epresentation range. * Special-casing the power-of-10 function for 10^-308. * Altered `get_normalized_components()` to not strive for better precision for near-extremal powers (at both ends) and settle for the "rougher" way to obtain the integral and decimal parts. * Added a test-case of a near-extremal-power which fails due to the re-normalization even if the powering is correct.
eyalroz
added a commit
that referenced
this issue
Feb 7, 2022
…epresentation range. * Special-casing the power-of-10 function for 10^-308. * Altered `get_normalized_components()` to not strive for better precision for near-extremal powers (at both ends) and settle for the "rougher" way to obtain the integral and decimal parts. * Added a test-case of a near-extremal-power which fails due to the re-normalization even if the powering is correct.
eyalroz
added a commit
that referenced
this issue
Feb 7, 2022
…epresentation range. * Special-casing the power-of-10 function for 10^-308. * Altered `get_normalized_components()` to not strive for better precision for near-extremal powers (at both ends) and settle for the "rougher" way to obtain the integral and decimal parts. * Added a test-case of a near-extremal-power which fails due to the re-normalization even if the powering is correct.
eyalroz
added a commit
that referenced
this issue
Feb 10, 2022
…epresentation range. * Special-casing the power-of-10 function for 10^-308. * Altered `get_normalized_components()` to not strive for better precision for near-extremal powers (at both ends) and settle for the "rougher" way to obtain the integral and decimal parts. * Added a test-case of a near-extremal-power which fails due to the re-normalization even if the powering is correct.
eyalroz
added a commit
that referenced
this issue
Feb 11, 2022
…epresentation range. * Special-casing the power-of-10 function for 10^-308. * Altered `get_normalized_components()` to not strive for better precision for near-extremal powers (at both ends) and settle for the "rougher" way to obtain the integral and decimal parts. * Added a test-case of a near-extremal-power which fails due to the re-normalization even if the powering is correct.
eyalroz
added
the
resolved-on-develop
A changeset fixing this issue has been commiutted to the development branch
label
Feb 20, 2022
kuba2k2
pushed a commit
to libretiny-eu/library-printf
that referenced
this issue
Feb 25, 2023
* Added a couple of test cases for exposing the behavior of the `#` modifier (alternative mode) together with `ll` (long long modifier), and specifically exposing the example format string mentioned in bug eyalroz#114. * Our fix for eyalroz#109 was too eager to keep `FLAG_HASH` - it dropped it only when a precision wasn't specified. We're now going part of the way back - dropping `FLAG_HASH` even when precision wasn't specific - except for octal. * The `long long` version of ntoa now behaves just like the `long` version.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
Something isn't working
resolved-on-develop
A changeset fixing this issue has been commiutted to the development branch
One of our test suite checks is:
we used not to get errors for this one... but that was before I refactored the log10 and pow10 computations... we used to get -307, incorrectly; and when it's 308, the pow10 computation exceeds the representable range of doubles, yielding infinity. This propagates along our code and results of all sorts of strange behavior when normalizing the number for printing; finally, we get a buffer of junk:
The text was updated successfully, but these errors were encountered: