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