From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 To: David Marchand Cc: "Medvedkin, Vladimir" , dev , Thomas Monjalon , Ferruh Yigit , dpdk stable , Konstantin Ananyev , Bernard Iremonger Subject: Re: [PATCH 12/12] test/ipsec: fix build with GCC 12 Message-ID: References: <20220518101657.1230416-1-david.marchand@redhat.com> <20220518101657.1230416-13-david.marchand@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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?