[PATCH] ecpg: use memcpy in a few length-based copies
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253024psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 06:42 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253024_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253024_1 && git checkout t253024_1Patchset v1 (message #1) is on t253024_1
Hi hackers,
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 add the
terminating NUL explicitly. There is also one small substring copy in
pgtypeslib/datetime.c. memcpy() seems a better fit for those cases.
I did not try to replace all strncpy() calls in ecpg. Some of them still need
the usual strncpy() behavior when the source string may be shorter than the
destination.
The patch also adds a small regression test for fixed-size char[] and VARCHAR
output around the exact-fit/truncation boundary.
Thanks,
Haibo
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 add 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.
At a quick glance, strlcpy() might be more suitable in some of the cases
you found.
On Thu, Jul 9, 2026 at 12:04 AM 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 add 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. The
sites I changed already have an explicit byte count, and some of them add the
terminating NUL immediately afterwards. So they are not relying on strncpy()’s
padding behavior.
At a quick glance, strlcpy() might be more suitable in some of the cases
you found.
I don’t think strlcpy() fits these cases well. It would reserve space 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 ECPG
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