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

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)
Date: 2024-06-24 01:14:01
Message-ID: CAEudQApOsin4JVJG+4WjZnGTV7ikEq+13s0F6PwjtgKWrBgzKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em dom., 23 de jun. de 2024 às 22:05, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
escreveu:

> Em dom., 23 de jun. de 2024 às 21:54, Michael Paquier <michael(at)paquier(dot)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.

best regards,
Ranier Vilela

>

Attachment Content-Type Size
v2-avoid-incomplete-copy-string-do_pg_backup_start.patch application/octet-stream 943 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2024-06-24 01:34:03 Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)
Previous Message Ranier Vilela 2024-06-24 01:05:42 Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)