mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chao Yu <yuchao0@huawei.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	<linux-f2fs-devel@lists.sourceforge.net>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] f2fs: Replace strncpy with memcpy
Date: Mon, 2 Jul 2018 10:57:09 +0800	[thread overview]
Message-ID: <ecb4f083-1d61-d882-c85c-53cb33fa793e@huawei.com> (raw)
In-Reply-To: <367fb12b-3ae0-4a6a-b59e-31d3a360bf05@roeck-us.net>

On 2018/7/2 10:16, Guenter Roeck wrote:
> On 07/01/2018 06:53 PM, Chao Yu wrote:
>> On 2018/7/2 4:57, Guenter Roeck wrote:
>>> gcc 8.1.0 complains:
>>>
>>> fs/f2fs/namei.c: In function 'f2fs_update_extension_list':
>>> fs/f2fs/namei.c:257:3: warning:
>>> 	'strncpy' output truncated before terminating nul copying
>>> 	as many bytes from a string as its length
>>> fs/f2fs/namei.c:249:3: warning:
>>> 	'strncpy' output truncated before terminating nul copying
>>> 	as many bytes from a string as its length
>>>
>>> Using strncpy() is indeed less than perfect since the length of data to
>>> be copied has already been determined with strlen(). Replace strncpy()
>>> with memcpy() to address the warning and optimize the code a little.
>>>
>>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>>> ---
>>>   fs/f2fs/namei.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
>>> index 231b7f3ea7d3..e75607544f7c 100644
>>> --- a/fs/f2fs/namei.c
>>> +++ b/fs/f2fs/namei.c
>>> @@ -246,7 +246,7 @@ int f2fs_update_extension_list(struct f2fs_sb_info *sbi, const char *name,
>>>   		return -EINVAL;
>>>   
>>>   	if (hot) {
>>> -		strncpy(extlist[count], name, strlen(name));
>>> +		memcpy(extlist[count], name, strlen(name));
>>
>> How about replacing with strcpy(extlist[count], name)? Because name length has
>> already been checked before f2fs_update_extension_list, it should be valid, and
>> will not cause overflow during copying.
>>
> 
> Your call; feel free to submit an alternative. Since it is different files, static
> analysis might not know and complain, though. You might want to make sure that this
> doesn't happen, and also add a comment explaining the reason for using strcpy().

Yeah, that could be changed in another patch, but it will be trivial. Anyway, to
fix this gcc complaint, this patch looks good to me, thanks for the patch. :)

Reviewed-by: Chao Yu <yuchao0@huawei.com>

Thanks,

> 
> Thanks,
> Guenter
> 
> 


  reply	other threads:[~2018-07-02  2:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-01 20:57 Guenter Roeck
2018-07-02  1:53 ` Chao Yu
2018-07-02  2:16   ` Guenter Roeck
2018-07-02  2:57     ` Chao Yu [this message]
     [not found]       ` <CAD14+f0eRF9y-QNMXwXEymQGOZ_D22sbdqwAuXg5Cv=SXryApQ@mail.gmail.com>
2018-07-10 15:58         ` [f2fs-dev] " Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ecb4f083-1d61-d882-c85c-53cb33fa793e@huawei.com \
    --to=yuchao0@huawei.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®