On Fri, Jul 23, 2021 at 03:30:01AM +0200, Vincent Lefevre wrote:
> On 2021-07-22 09:11:56 -0700, Kevin J. McCarthy wrote:
> > What do you think of using memccpy in the strfcpy macro,
>
> IMHO, it is better than strncpy, which unnecessarily pads with
> null bytes.
>
> > if it's available, as Ian s
On 2021-07-22 09:11:56 -0700, Kevin J. McCarthy wrote:
> What do you think of using memccpy in the strfcpy macro,
IMHO, it is better than strncpy, which unnecessarily pads with
null bytes.
> if it's available, as Ian suggested?
The Linux memccpy(3) man page says:
CONFORMING TO
POSIX.1-20
On Thu, Jul 22, 2021 at 09:11:56AM -0700, Kevin J. McCarthy wrote:
What do you think of using memccpy in the strfcpy macro, if it's
available, as Ian suggested?
I've pushed a commit up to branch `kevin/warnings` doing this.
memccpy() returns a different value than strncpy(), but it doesn't
ap
On Thu, Jul 22, 2021 at 12:11:17PM +0200, Vincent Lefevre wrote:
Silence strfcpy() warning in dotlock_deference_symlink().
Yeah, I thought about this commit for a while, because I wasn't joyful
about making the change just to silence the compiler in this case.
The other warning-fix commit
On Thu, Jul 22, 2021 at 12:11:17PM +0200, Vincent Lefevre wrote:
> I actually think that the compiler should warn in every case,
> but isn't able to detect all potential issues. The strfcpy
> definition seems wrong:
>
> # define strfcpy(A,B,C) strncpy (A,B,C), *(A+(C)-1)=0
>
> If A and B are buff
Concerning the commit
commit 8970a4793c302c0bb8619a5dde56c8ca8de20532
Author: Kevin McCarthy
Date: 2021-07-21 22:26:25 +0200
Silence strfcpy() warning in dotlock_deference_symlink().
The compiler is being a bit strange, only picking out and warning
about the 'strfcpy (d, pathp
