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
On Mon, Nov 8, 2021 at 9:42 AM Ajay Garg <ajaygargnsit@gmail.com> wrote:

...

> >> len = [-7]
> >> a = [123456789]
> >
> > My gosh, this is error code that you must check. We do not need more string copy functions.
>
> Hmm, having the additional function would make things a lot easier.
>
> For example, in file fs/kernfs/dir.c, there are methods like
> "kernfs_name_locked", "kernfs_path_from_node_locked" which simply
> consume the return-value without any checks.
>
> All the above functions have a simple motive : copy as much bytes as
> possible in the destination buffer, and then consume/return the number
> of bytes actually copied (minus the null-terminator byte of course).

Nope. Read the comment WRT strscpy().

> If checks are to be put in-place, it would be too much code/churn,
> adding if checks all over the place.

Yep, that's why in some cases where we know that there can't be
overflow the checks are not present. In some cases it's historically
like this, in some cases checks might be useful and so on. But no, we
do not need more chaos in the string functions.

> If, instead we do a simple replace of "strlcpy" with "strlscpy" at
> these places, we would be good to go (while *really* meeting the
> requirements of these clients at the same time).

--
With Best Regards,
Andy Shevchenko

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