From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id CEB1CA0557;
	Fri,  3 Jun 2022 09:56:10 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id B003940694;
	Fri,  3 Jun 2022 09:56:10 +0200 (CEST)
Received: from mga12.intel.com (mga12.intel.com [192.55.52.136])
 by mails.dpdk.org (Postfix) with ESMTP id 0A88640691;
 Fri,  3 Jun 2022 09:56:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
 d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
 t=1654242969; x=1685778969;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:in-reply-to;
 bh=L0hLXXljMiGWxW40CE6HMoly+Z7s+PnXiR9qdVZ2AQ8=;
 b=biZTbOB+gts3YMQnsBcj3hE4sJkY2qoC9vXZMDiBfEh2JkV/ZsuPdUbu
 DIvUtp4+Q2+A5xTR7K1YMyvWKth0nS7meimO4W+WVrweOejCukAYVqw2j
 XErQ13oL/2PcfsEq8tweZpOFI4oxcAZOihT/UU67ncQYcsuj64RcxTLT8
 uX82rIVhhqkQBJ4ou3OHc8fBbyN8jMipFyMDaFsNUmPIPxHlI+rElY6KJ
 Pe4Yh1Y3+2R4s3h6FTBhB0pKBdSTS3gejNaQELFEEZ6Tzh9pC5MvqcW5l
 edXdo3m86r0wVcf/+VjJ0TV9S6DFb8FQ5G+HZpbZf2jKylj/62eZaMRRs Q==;
X-IronPort-AV: E=McAfee;i="6400,9594,10366"; a="256059396"
X-IronPort-AV: E=Sophos;i="5.91,274,1647327600"; d="scan'208";a="256059396"
Received: from fmsmga005.fm.intel.com ([10.253.24.32])
 by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 03 Jun 2022 00:56:08 -0700
X-IronPort-AV: E=Sophos;i="5.91,274,1647327600"; d="scan'208";a="905367301"
Received: from bricha3-mobl.ger.corp.intel.com ([10.252.6.223])
 by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA;
 03 Jun 2022 00:56:06 -0700
Date: Fri, 3 Jun 2022 08:56:03 +0100
From: Bruce Richardson <bruce.richardson@intel.com>
To: David Marchand <david.marchand@redhat.com>
Cc: "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>,
 dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>,
 Ferruh Yigit <ferruh.yigit@xilinx.com>, dpdk stable <stable@dpdk.org>,
 Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>,
 Bernard Iremonger <bernard.iremonger@intel.com>
Subject: Re: [PATCH 12/12] test/ipsec: fix build with GCC 12
Message-ID: <Ypm+k8LuYEEJkpHP@bricha3-MOBL.ger.corp.intel.com>
References: <20220518101657.1230416-1-david.marchand@redhat.com>
 <20220518101657.1230416-13-david.marchand@redhat.com>
 <ccefe759-73db-9655-ed7a-0f4cc8b80556@intel.com>
 <CAJFAV8warH7pMydChieiEy7fheRCVnSm6tNrEuFzyw=arL5aoQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJFAV8warH7pMydChieiEy7fheRCVnSm6tNrEuFzyw=arL5aoQ@mail.gmail.com>
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Fri, Jun 03, 2022 at 09:45:45AM +0200, David Marchand wrote:
> Hello Vladimir,
> 
> On Thu, Jun 2, 2022 at 8:42 PM Medvedkin, Vladimir
> <vladimir.medvedkin@intel.com> wrote:
> > >               if (!dst) {
> > >                       rte_pktmbuf_free(m);
> > >                       return NULL;
> > >               }
> > > -             if (string != NULL)
> > > -                     rte_memcpy(dst, string, t_len);
> > > -             else
> > > -                     memset(dst, 0, t_len);
> > > +             if (string != NULL) {
> > > +                     size_t off;
> > > +
> > > +                     for (off = 0; off + string_len < len; off += string_len)
> >
> > I think it should be off + string_len <= len here, because otherwise, if
> > len is a multiple of string_len, the last ret_memcpy (after this loop)
> > will copy 0 bytes.
> 
> Changing to off + string_len <= len would trigger an oob access to dst
> (by one extra byte)?
> Otoh, I don't think it is an issue to have a 0-length call to rte_memcpy.
> 
Given this is test code, do we need rte_memcpy for performance over regular
libc memcpy? Does fixing the warning become any easier or clearer if libc
memcpy is used?