| From: | surya poondla <suryapoondla4(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Prashant Chinnam <crprashant(at)hotmail(dot)com> |
| Subject: | Re: Return INT_MAX or INT_MIN from strtoint() on overflow |
| Date: | 2026-10-29 20:44:42 |
| Message-ID: | CAOVWO5pJLQ5Pz5NLwUM4-6aSmjEzjsHrDCybqBmb+6S7f16P8Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Chao,
I'm not sure if the change is needed.
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.
On Windows, where long is 32 bits, strtol() already returns
INT_MAX/INT_MIN, so nothing changes there either.
The only callers that see a difference are the ones that ignore errno:
pgcrypto's px_crypt_shacrypt() and a few ecpg pgtypeslib/dt_common.c paths.
For those, the real bug is that they don't check errno.
Regards,
Surya Poondla
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Lelarge | 2026-10-29 20:45:54 | Setting the number of digits after the decimal point with a psql's pset variable |
| Previous Message | Greg Burd | 2026-10-29 20:38:57 | Re: Showing "Table Block Fetches" in EXPLAIN ANALYZE for index-only scans |