lkml.org 
[lkml]   [2021]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: RFC for a new string-copy function, using mixtures of strlcpy and strscpy
Thanks Keen for your time.

>
> For the specific fs/kerfs/dir.c case, I don't see any problems --
> nothing uses the result (cgroup_name() is the only caller of
> kernfs_name() that I see).
>

I am not worried about this single case as per say.

My intention is to make the lives easier for clients in general, who
have the simple motive : to copy as many bytes as possible, and then
consume/propogate the return-value containing number of bytes
*actually* copied, without having to resort to the identical
4-lines-per-check-fix everywhere.

I think you and me agree on the pain-points of using strlcpy/strscpy.

The general consensus is that no new string-functions should be added
as of now, so I guess every client would require 4-lines-per-check-fix
as of now (wherever applicable of course).

Maybe, the RFC for new function could be discussed in the next
opportune moment, which would then be a simple drop-in replacement,
resulting in 1-lines-per-check-fix (wherever applicable of course).


Thanks and Regards,
Ajay

\
 
 \ /
  Last update: 2021-11-08 20:22    [W:0.715 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site