Horton

Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)

Ranier Vilela <ranier.vf@gmail.com>

View thread
From: Ranier Vilela <ranier.vf@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Fabrízio de Royes Mello <fabriziomello@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2024-06-24T01:34:03Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Use safe string copy routine

Attachments

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
>
>>