From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0CA00A04BC; Fri, 9 Oct 2020 12:36:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 494FC1D165; Fri, 9 Oct 2020 12:36:40 +0200 (CEST) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by dpdk.org (Postfix) with ESMTP id DBD941D161 for ; Fri, 9 Oct 2020 12:36:37 +0200 (CEST) X-Originating-IP: 86.254.165.59 Received: from u256.net (lfbn-poi-1-843-59.w86-254.abo.wanadoo.fr [86.254.165.59]) (Authenticated sender: grive@u256.net) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 0B3AE1BF206; Fri, 9 Oct 2020 10:36:35 +0000 (UTC) Date: Fri, 9 Oct 2020 12:36:30 +0200 From: =?utf-8?Q?Ga=C3=ABtan?= Rivet To: Ferruh Yigit Cc: Bruce Richardson , Olivier Matz , Ciara Loftus , dev@dpdk.org Message-ID: <20201009103630.jicsmryvgsxc72bl@u256.net> References: <20201007090137.5121-1-ciara.loftus@intel.com> <20201007095131.GQ21395@platinum> <20201007102638.GB680@bricha3-MOBL.ger.corp.intel.com> <20201007102812.GC680@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 07/10/20 12:45 +0100, Ferruh Yigit wrote: > On 10/7/2020 11:28 AM, Bruce Richardson wrote: > > On Wed, Oct 07, 2020 at 11:26:38AM +0100, Bruce Richardson wrote: > > > On Wed, Oct 07, 2020 at 11:51:31AM +0200, Olivier Matz wrote: > > > > On Wed, Oct 07, 2020 at 10:40:32AM +0100, Ferruh Yigit wrote: > > > > > On 10/7/2020 10:01 AM, Ciara Loftus wrote: > > > > > > strncpy may leave the destination buffer not NULL terminated so use > > > > > > snprintf instead. > > > > > > > > > > What do you think using 'strlcpy'? > > > > > > > > Or even better, rte_strscpy() > > > > https://git.dpdk.org/dpdk/commit/?id=b0236c7cf761 > > > > > > > I think this is largely a matter of preference, and unless there is a good > > > reason not to, I tend towards strlcpy as the older and more common (till > > > now) interface. The main thing is just to use a function that will > > > guarantee dest is null-terminated here, and both strlcpy and strscpy meet > > > that criteria. > > > > > I'd also add that strlcpy is more likely to be recognised by tools like > > coverity, compared to rte_strscpy which is DPDK-specific. > > > > +1 to 'strlcpy' Using strlcpy will be more recognized by static analyzer indeed. But strscpy API is better: * It helps checking string truncation by making it easier: if (strlcpy(dst, src, dstsize) >= dstsize) /* Dev + reviewer needs to think about using >= and not >, dstsize is * repeated so either dst is an array or it needs a dedicated variable. * Deal with truncation. */ if (rte_strscpy(dst, src, dstsize) < 0) /* deal with truncation. */ * It is safer when dealing with unknown data source. strlcpy will always read all of src, because the API (uselessly) defines the return value to strlen(src). Having yet another string copy function is contentious, but we can avoid using worse API to please tools. And detecting string truncation *is* helpful. String are used as IDs in DPDK for some objects. Using strlcpy / snprintf at least protects from buffer overflow, which is a bare minimum. A good implementation would also warn the user about a config error / memory corruption happening sooner. In any case, sure to fix a sanity check strlcpy / snprintf will work. Cheers, -- Gaëtan