Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c) - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)
Date
Msg-id CAEudQAp2L2GBMwiH6+OO5ZAnZmq2zdUEAu1=VMpYhdRUWvakEQ@mail.gmail.com
Whole thread Raw
In response to Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)  (Ranier Vilela <ranier.vf@gmail.com>)
List pgsql-hackers
Em dom., 23 de jun. de 2024 às 22:14, Ranier Vilela <ranier.vf@gmail.com> escreveu:
Em dom., 23 de jun. de 2024 às 22:05, Ranier Vilela <ranier.vf@gmail.com> escreveu:
Em dom., 23 de jun. de 2024 às 21:54, Michael Paquier <michael@paquier.xyz> escreveu:
On Sun, Jun 23, 2024 at 09:34:45PM -0300, Ranier Vilela wrote:
> It's not critical code, so I think it's ok to use strlen, even because the
> result of strlen will already be available using modern compilers.
>
> So, I think it's ok to use memcpy with strlen + 1.

It seems to me that there is a pretty good argument to just use
strlcpy() for the same reason as the one you cite: this is not a
performance-critical code, and that's just safer.
Yeah, I'm fine with strlcpy. I'm not against it.
Perhaps, like the v2?

Either v1 or v2, to me, looks good.
Thinking about, does not make sense the field size MAXPGPATH + 1.
all other similar fields are just MAXPGPATH.

If we copy MAXPGPATH + 1, it will also be wrong.
So it is necessary to adjust logbackup.h as well.

So, I think that v3 is ok to fix.

best regards,
Ranier Vilela

best regards,
Ranier Vilela
Attachment

pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)
Next
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Conflict detection and logging in logical replication