GeezerVison

Nit: I'm wondering whether there's a better name here; the "max" part seems potentially confusing (the max value stored here would be 5**2**9, right?). Bigint_Pow5count? Bigint_Pow5size?

I renamed it to Bigint_Pow5size

Nit: Could we adjust this comment to be more explicit about the indexing - i.e., make it clear that p5s[i] is 5**(2**(i+2)) for 0 <= i < Bigint_Pow5max?

Deleted because the comment is out of date, presumably? 👍

Yeah, these comments were about why the below functions used PyAPI_FUNC (were "exported"), but the symbols are no longer exported.

This single line is by far the hardest to review, and reminds me yet again why I'd be delighted to see dtoa.c go away entirely. :-)

This says that pow5mult will never be called with k >= 1024, right?

I do believe that there's an upper limit on possible k values here, based on:

• For double-to-string conversion, our input space is naturally bounded, and since we're assuming IEEE 754 binary64 format, we have at most 767 significant decimal digits in any output (an example worst case is something like (2**53 - 1) * 2**-1074), and dtoa.c is clever enough to pad with zeros when requested (e.g., with something crazy like format(math.pi, '.2000f')) rather than try to compute those zeros.
• For string-to-double conversion, the input string has a potentially unbounded number of decimal digits, all of which may need to be taken into account for correct-rounding corner cases, but in those corner cases dtoa.c (in bigcomp) takes the approach of computing decimal digits of binary64 tie values and comparing with the decimal input, rather than trying to convert the decimal input to bigint-land (which would potentially require huge powers of 5).

And based on the above, 1023 certainly seems plausible as an upper bound for possible k values. I'd be hard pushed to give a proof that k can never exceed 1023, though. (At least, not without spending a lot more time than I currently have available.)

@colesbury Does the above roughly match your reasoning? Would it be possible to add a comment to the code justifying the assertion?

I've added a comment and moved the assertion up. The limits are related to the maximum base-10 exponent. For double-to-string, that's DBL_MAX_10_EXP (308). As you say, we set the limits ourselves for string-to-double, which are e=308 for overflow and e=-512 for underflow. But our exponent can be adjusted based on the number of digits, so we can see values as larges as k=535 float('1' +'0'*38 + '1E-535'), where the limits is from the combination of 512+STRTOD_DIGLIM-DBL_DIG-1.