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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Prashant Chinnam <crprashant(at)hotmail(dot)com>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, surya poondla <suryapoondla4(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Takeshi Ideriha <iderihatakeshi(at)gmail(dot)com>
Subject: Re: Return INT_MAX or INT_MIN from strtoint() on overflow
Date: 2026-10-30 15:07:26
Message-ID: 2387761.1793372846@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Prashant Chinnam <crprashant(at)hotmail(dot)com> 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.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Salma Elsayed 2026-10-30 15:25:14 Re: PoC: Simplify recovery after dropping a table by LOGGING the restore LSN
Previous Message Fujii Masao 2026-10-30 14:59:43 Re: Wrong LSN in WAL decoding error messages