Em dom., 23 de jun. de 2024 às 22:14, Ranier Vilela <ranier...@gmail.com> escreveu:
> Em dom., 23 de jun. de 2024 às 22:05, Ranier Vilela <ranier...@gmail.com> > escreveu: > >> Em dom., 23 de jun. de 2024 às 21:54, Michael Paquier < >> mich...@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 > >>
v3-avoid-incomplete-copy-string-do_pg_backup_start.patch
Description: Binary data
