| 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
| 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 |