connman.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Santtu Lakkala <santtu.lakkala@jolla.com>
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
	<Emmanuel.VAUTRIN@cpexterne.org>,
	"Lukáš Karas" <lukas.karas@centrum.cz>,
	"connman@lists.linux.dev" <connman@lists.linux.dev>
Subject: Re: [PATCH] replace strncopy by memcpy
Date: Fri, 18 Jun 2021 20:53:25 +0300	[thread overview]
Message-ID: <18824313-c5d2-cc30-dcbf-006a82c5ff75@jolla.com> (raw)
In-Reply-To: <PR1PR02MB4794D05CFF3F4C689F28ECC0930D9@PR1PR02MB4794.eurprd02.prod.outlook.com>

On 18.6.2021 15.38, VAUTRIN Emmanuel (Canal Plus Prestataire) wrote:
> Thank you for your patch, but, even if I have not checked the
> related sources, I really doubt about your fix. Maybe it will not
> be a problem, due to the following check:
> if ((uptr + ulen) > uncomp_end)
>   			goto out;
> 
>> memcpy is equivalent to strncpy here as pointed by Santtu.
> Please be careful, no more warning does not always imply that
> the problem has been fixed. The warning has only disappear here
> because you have replaced the call to strncpy by another one.
> memcpy and  strncpy are not equivalent.
> strncpy is dedicated to string processing, and enables to avoid not
> null terminated strings, when the string length is equal to the destination
> buffer size.
> The good fix is just to replace, in the strncpy call,  ulen by  ulen -1 or
> strlen(name).
> If you really want to propose a patch, please refer to the commits
> (sources code + commit message) I mentioned
> (90f0e412569b327d8b25b834623b814f1fddbd19
> & 3dbcc963a66d43e4ac51c97de4fe116ec72eb9f6),
> it will be a better approach.

This is a different warning, this warning is about using strlen(src) as 
strncpy() length argument. I see a few possible fixes to acknowledge the 
warning:
  1) replace strncpy with memcpy (as done in this patch, no change in 
behavior, only theoretically slightly more performant)
  2) replace strncpy with strcpy (available space is already checked)
  3) replace strncpy length argument with available buffer space (would 
unnecessarily zero the buffer to the end)
  4) change the whole paradigm, and do something like:
     uptr += snprintf(uptr, uncomp_end - uptr, "%s", name);
     if (uptr >= uncomp_end)
         goto out;
  5) do 4 with strlcpy, but we don't have that

-- 
Santtu

  reply	other threads:[~2021-06-18 17:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-18 12:38 [PATCH] replace strncopy by memcpy VAUTRIN Emmanuel (Canal Plus Prestataire)
2021-06-18 17:53 ` Santtu Lakkala [this message]
2021-06-21  7:00   ` Daniel Wagner
  -- strict thread matches above, loose matches on Subject: below --
2021-06-18  9:27 Lukáš Karas

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=18824313-c5d2-cc30-dcbf-006a82c5ff75@jolla.com \
    --to=santtu.lakkala@jolla.com \
    --cc=Emmanuel.VAUTRIN@cpexterne.org \
    --cc=connman@lists.linux.dev \
    --cc=lukas.karas@centrum.cz \
    /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;
as well as URLs for NNTP newsgroup(s).