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 CAEudQAqPePSd3z_U8SmZSYh2HVxy3OKCNCVn+ksFESQa1EwSvQ@mail.gmail.com
Whole thread Raw
In response to Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)
List pgsql-hackers
Em seg., 1 de jul. de 2024 às 16:20, Daniel Gustafsson <daniel@yesql.se> escreveu:
> On 1 Jul 2024, at 21:15, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> On 2024-Jul-01, Ranier Vilela wrote:

>>> -       char            name[MAXPGPATH + 1];
>>> +       char            name[MAXPGPATH];/* backup label name */
>>>
>>> With the introduced use of strlcpy, why do we need to change this field?
>>>
>> The part about being the only reference in the entire code that uses
>> MAXPGPATH + 1.
>
> The bit I don't understand about this discussion is what will happen
> with users that currently have exactly 1024 chars in backup names today.
> With this change, we'll be truncating their names to 1023 chars instead.
> Why would they feel that such change is welcome?

That's precisely what I was getting at.  Maybe it makes sense to change, maybe
not, but that's not for this patch to decide as that's a different discussion
from using safe string copying API's.
Ok, this is not material for the proposal and can be considered unrelated.

We only have to replace it with strlcpy.

v7 attached.

best regards,
Ranier Vilela
Attachment

pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: Optimize numeric multiplication for one and two base-NBASE digit multiplicands.
Next
From: Robert Haas
Date:
Subject: Re: optimizing pg_upgrade's once-in-each-database steps