Date: Wed, 26 May 2021 17:35:30 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Incorrect usage of strtol, atoi for non-numeric junk inputs
Message-ID: <202105262135.zcl7jtvfz3v7@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CALj2ACXqdG9WhqVoJ9zYf-iZt7sgK7Szv5USs=he6NnWQ2ofTA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202105262135.zcl7jtvfz3v7%40alvherre.pgsql>
Precedence: bulk

On 2021-May-19, Bharath Rupireddy wrote:

> While working on [1], I found that some parts of the code is using
> strtol and atoi without checking for non-numeric junk input strings. I
> found this strange. Most of the time users provide proper numeric
> strings but there can be some scenarios where these strings are not
> user-supplied but generated by some other code which may contain
> non-numeric strings. Shouldn't the code use strtol or atoi
> appropriately and error out in such cases?  One way to fix this once
> and for all is to have a common API something like int
> pg_strtol/pg_str_convert_to_int(char *opt_name, char *opt_value) which
> returns a generic message upon invalid strings ("invalid value \"%s\"
> is provided for option \"%s\", opt_name, opt_value) and returns
> integers on successful parsing.

Hi, how is this related to
https://postgr.es/m/20191028012000.GA59064@begriffs.com ?

-- 
Álvaro Herrera       Valdivia, Chile