Re: why in appendShellStringNoError() loop still continues even after it found CR or LF?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Srinath Reddy <srinath2133(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: why in appendShellStringNoError() loop still continues even after it found CR or LF?
Date: 2025-04-25 12:52:54
Message-ID: CA+TgmobkFWRas7Pt4m7GpkfcNznbaVkRS4Bd-pMhuXE_W20jOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Mar 29, 2025 at 8:37 AM Srinath Reddy <srinath2133(at)gmail(dot)com> wrote:
> i have naive doubt $SUBJECT,AFAIK The reasoning would be this function is designed to silently filter out \n and \r while still producing a usable shell-safe argument. It informs the caller of the issue (false return value) but does not abruptly stop execution,then the caller will decide what to do but every place this function is called they are just throwing the error.

That is true, but one of the two call sites exits the program, and the
other does not, so the cases are different.

> if theres no proper reason to loop and continue we can use strpbrk and return false when we found \n or \r.

I don't know what you mean by this. There are comments within
appendShellStringNoError and atop appendShellString which explain the
intended behavior, and the function seems to correctly implement that
behavior in a pretty straightforward way. While it's probably true
that someone could have chosen to use strpbrk, I don't see any real
advantage to that over the way it was actually done.

Returning as soon as an \r or \n is found would change the documented
behavior, so one couldn't make that change without carefully
considering the implications for the callers.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2025-04-25 12:53:04 Re: Making sslrootcert=system work on Windows psql
Previous Message Sutou Kouhei 2025-04-25 12:45:34 Re: Make COPY format extendable: Extract COPY TO format implementations