Messages in this thread | | | From | Ajay Garg <> | Date | Tue, 9 Nov 2021 00:50:58 +0530 | Subject | Re: 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
| |