Re: Incorrect usage of strtol, atoi for non-numeric junk inputs

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Incorrect usage of strtol, atoi for non-numeric junk inputs
Date: 2021-06-04 15:28:04
Message-ID: 202106041528.5gt6owi2kq6m@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-Jun-04, Bharath Rupireddy wrote:

> On Thu, May 27, 2021 at 3:05 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > Hi, how is this related to
> > https://postgr.es/m/20191028012000.GA59064@begriffs.com ?
>
> Thanks. The proposed approach there was to implement postgres's own
> strtol i.e. string parsing, conversion to integers and use it in the
> places where atoi is being used. I'm not sure how far that can go.
> What I'm proposing here is to use strtol inplace of atoi to properly
> detect errors in case of inputs like '1211efe', '-14adc' and so on as
> atoi can't detect such errors. Thoughts?

Well, if you scroll back to Surafel's initial submission in that thread,
it looks very similar in spirit to what you have here.

Another thing I just noticed which I hadn't realized is that Joe
Nelson's patch depends on Fabien Coelho's patch in this other thread,
https://www.postgresql.org/message-id/flat/alpine(dot)DEB(dot)2(dot)21(dot)1904201223040(dot)29102(at)lancre
which was closed as returned-with-feedback, I suppose mostly due to
exhaustion/frustration at the lack of progress/interest.

I would suggest that the best way forward in this area is to rebase both
there patches on current master.

--
Álvaro Herrera Valdivia, Chile
"La virtud es el justo medio entre dos defectos" (Aristóteles)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2021-06-04 15:42:29 Re: security_definer_search_path GUC
Previous Message Greg Sabino Mullane 2021-06-04 15:16:36 Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM