> On Oct 30, 2026, at 23:07, Tom Lane <[email protected]> wrote:
>
> Prashant Chinnam <[email protected]> writes:
>> Hi Tom,
>>> My thought here is to back-patch the strtoint() change.
>>> I cannot envision any case that that would make worse.
>>> And failing to do so leaves a land-mine for potential
>>> future back-patches of code using strtoint().
>
>> Thanks -- back-patching the strtoint() change removes my
>> only reason for preferring strtoi64() in patch [1]. Once
>> it has landed, I will switch that patch back to
>> strtoint(); that was the shape of my original v1, minus
>> the errno workaround that the saturating return value
>> makes unnecessary.
>
> Pushed. I made the code look like this:
>
> val = strtol(str, endptr, base);
> if (val != (int) val)
> + {
> + val = (val < 0) ? INT_MIN : INT_MAX;
> errno = ERANGE;
> + }
> return (int) val;
>
> I was concerned that Chao's original formulation could provoke
> compiler warnings on machines with 32-bit long: it would not
> be surprising to get "condition is always false" warnings
> from "val > INT_MAX" etc. (In principle the existing test
> could provoke such warnings too, but it doesn't. I very
> vaguely recall that we settled on the cast-and-compare
> method specifically to avoid warnings, way back when.)
Happy to learn that.
Thanks for pushing.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
