The preprocessor definition
NUM_DECIMAL_DIGITS_IN_FP_INTEGRAL_COMPONENT_T is currently set regardless of our choice of the actual type used for printf_fp_uint_t, i.e. regardless of the choice of PRINTF_USE_DOUBLE_INTERNALLY / FP_TYPE_MANT_DIG. But - naturally, it has to correspond to thise choice. One of the consequences of non-correspondence is an out-of-bounds access to the precomputed powers_of_10 array, as its size does correspond to that choice. Let's define it according to what we now have for PRINTF_MAX_PRECOMPUTED_POWER_OF_10 (i.e. 10 or 17).
Thanks for @dbeinder for pointing out there's a problem - see PR #229.
Also note that I believe it may be reasonable to change the value-pair 11,18 to 9,18 - according to the rounded-up log_10 values of the maximum representable integer in fp_uint_t; but that's a matter for another issue.
The preprocessor definition
NUM_DECIMAL_DIGITS_IN_FP_INTEGRAL_COMPONENT_Tis currently set regardless of our choice of the actual type used forprintf_fp_uint_t, i.e. regardless of the choice ofPRINTF_USE_DOUBLE_INTERNALLY/FP_TYPE_MANT_DIG. But - naturally, it has to correspond to thise choice. One of the consequences of non-correspondence is an out-of-bounds access to the precomputedpowers_of_10array, as its size does correspond to that choice. Let's define it according to what we now have forPRINTF_MAX_PRECOMPUTED_POWER_OF_10(i.e. 10 or 17).Thanks for @dbeinder for pointing out there's a problem - see PR #229.
Also note that I believe it may be reasonable to change the value-pair 11,18 to 9,18 - according to the rounded-up log_10 values of the maximum representable integer in
fp_uint_t; but that's a matter for another issue.