Chao Li <[email protected]> writes:
>> On Oct 30, 2026, at 04:44, surya poondla <[email protected]> wrote:
>> strtoint() job has always been to detect overflow through errno. All the
>> core callers in that style (datetime.c, read.c, tsearchcmds.c, jsonfuncs.c,
>> psql, option_utils.c) check errno == ERANGE and never
>> look at the return value after an overflow. For them v1 changes nothing.
> That’s true, but it doesn’t mean the current return-value behavior matches
> the header comment.
Yeah. POSIX is 100% clear about what strtol is required to do:
If the correct value is outside the range of representable values,
{LONG_MIN}, {LONG_MAX}, {LLONG_MIN}, or {LLONG_MAX} shall be
returned (according to the sign of the value), and errno set to
[ERANGE].
So a bitwise-truncated value is not OK; we must preserve the original
sign in case the caller wants to know that, and we must ensure that
callers' range checks deliver sensible results. Even if none of our
in-core callers cared at the moment, it makes sense to me that we
should match this behavior. All the more reason if there are places
that could immediately make use of the tighter API spec.
regards, tom lane
