Re: Return INT_MAX or INT_MIN from strtoint() on overflow

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