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

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

In response to

Browse pgsql-hackers by date

  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