Consider unifying _ntoa_long and _ntoa_long_long #115
Comments
|
Well, it's done on my fork, that wasn't so hard... |
eyalroz
referenced
this issue
in eyalroz/printf
Aug 2, 2021
… `ntoa` function. * Defined an `NTOA_VALUE_TYPE` based on whether `long long` is supported. * Using an `NTOA_ABS()` macro instead of repeating the one-liner code used earlier; and it eagerly casts to avoid problems with extremal negative values.
eyalroz
referenced
this issue
in eyalroz/printf
Aug 3, 2021
… `ntoa` function. * Defined an `NTOA_VALUE_TYPE` based on whether `long long` is supported. * Using an `NTOA_ABS()` macro instead of repeating the one-liner code used earlier; and it eagerly casts to avoid problems with extremal negative values.
KarlK90
pushed a commit
to qmk/printf
that referenced
this issue
Jul 7, 2022
…trema of the representation 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When
llis supported, why should we have both_ntoa_longand_ntoa_long_long? They do the exact same thing, except for the different types. Why not just put the value in along longand use just one of the functions? It's not as though we care that much about the performance cost or stack size along thelongpath that saving 2 or 4 bytes matters so much... after all, we don't have_ntoa_short.@mickjc750 : This is your idea originally.
The text was updated successfully, but these errors were encountered: