Greg Stark <stark@mit.edu> writes:
> Hmm. The backtrace is here but I think it's lying about the specific line.
> #0 convert_one_string_to_scalar (value=0x7f20e9a3 " ",
> rangelo=32, rangehi=122, 2132863395, 32, 122)
> at selfuncs.c:3873
> #1 0x00435880 in convert_string_to_scalar (
> value=0x7f20e990 "Aztec\n", ' ' <repeats 11 times>, "Ct ",
> scaledvalue=0x7fffdb44,
> lobound=0x7f225bf4 "Audrey", ' ' <repeats 24 times>, "Dr ",
> scaledlobound=0x7fffdb34,
> hibound=0x7f225c40 "Balmoral", ' ' <repeats 22 times>, "Dr ",
> scaledhibound=0x7fffdb3c, 2132863376, 2147474244, 2132958196,
> 2147474228, 2132958272, 2147474236) at selfuncs.c:3847
> Stepping through the code it looks like it actually happens on line
> 3882 when denom overflows.
Oh, interesting. The largest possible value of "base" is 256, and the
code limits the amount of string it'll scan to 20 bytes, which means
"denom" could reach at most 256^21 = 3.7e50. Perfectly fine with
IEEE-math doubles, but not so much with other arithmetics.
We could hold the worst-case value to within the VAX range if we
considered only about 14 bytes instead of 20. Probably that wouldn't
lose much in terms of estimation accuracy, but given the lack of
complaints to date, I'm not sure we should change it ...
regards, tom lane
