Hi Chao, +1 -- I ran into exactly this while writing patch [1].
My first version used strtoint() with an errno check, but the returned value could not be trusted to show the direction of the overflow, so the clamp direction had to be taken from the input string instead. A saturating return value, as strtol() provides, is what that code actually wanted. While looking at this I audited the in-tree strtoint() callers: 33 call sites, of which 21 check errno and discard the value on overflow, so they are unaffected. The other 12 are all in ecpg's dt_common.c, which does not check errno; for those, saturation seems strictly safer than a truncated value, and I found no caller that relies on the truncated result. Two paths there might be worth a look either way: the DecodeTimezone colon form has no range check on the parsed hour and minute, and the DecodeTime hour bound is similar. Neither is made worse by this change. On patch [1]: I intend to keep strtoi64() there even if this lands, because the pgcrypto fix is meant to be backpatched to REL_18_STABLE, where strtoint() keeps its current behavior, while strtoi64() behaves the same on both branches. Happy to follow a different direction if committers prefer otherwise. The caller audit above was done with AI assistance. Regards, Prashant Chinnam
