MIME-Version: 1.0
References: 
 <CABXr29HdcPfU+wC7Va9Z5WXh+Kai_63J4J-e3d-_w=EuBNFKLw@mail.gmail.com>
 <d3384f44-412a-47b4-b5b9-cdc64a336d2f@eisentraut.org>
In-Reply-To: <d3384f44-412a-47b4-b5b9-cdc64a336d2f@eisentraut.org>
From: Haibo Yan <tristan.yim@gmail.com>
Date: Thu, 9 Jul 2026 21:07:58 -0700
Message-ID: 
 <CABXr29FNSLOo3F6uv8JYRDVVrprG0JafMhVGWyjrumf2e-F_4A@mail.gmail.com>
Subject: Re: [PATCH] ecpg: use memcpy in a few length-based copies
To: Peter Eisentraut <peter@eisentraut.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CABXr29FNSLOo3F6uv8JYRDVVrprG0JafMhVGWyjrumf2e-F_4A%40mail.gmail.com>
Precedence: bulk

On Thu, Jul 9, 2026 at 12:04=E2=80=AFAM Peter Eisentraut <peter@eisentraut.=
org> wrote:
>
> On 08.07.26 21:24, Haibo Yan wrote:
> > I noticed a few places in ecpg that use strncpy() even though the code =
already
> > knows how many bytes to copy.
> >
> > For example, some paths copy N bytes into a temporary buffer and then a=
dd the
> > terminating NUL explicitly.  There is also one small substring copy in
> > pgtypeslib/datetime.c.  memcpy() seems a better fit for those cases.
>
> Why is it better?  At least strncpy() enforces that the target is a char
> array, which memcpy() doesn't.

Thank you. I should have explained that better.

I am not arguing that memcpy() is generally better for string handling.  Th=
e
sites I changed already have an explicit byte count, and some of them add t=
he
terminating NUL immediately afterwards.  So they are not relying on strncpy=
()=E2=80=99s
padding behavior.

>
> At a quick glance, strlcpy() might be more suitable in some of the cases
> you found.
>

I don=E2=80=99t think strlcpy() fits these cases well.  It would reserve sp=
ace for a
terminator, which would change exact-fit/truncation behavior in some output
paths.  It also treats the source as a NUL-terminated C string, while the E=
CPG
VARCHAR case is an arr/len buffer, not just a plain C string.

I left other strncpy() calls unchanged where the source may be shorter than=
 the
fixed-size destination, because there the stop-at-NUL and padding behavior =
is
still useful.

Thanks,
Haibo