From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 7BEAAA0679 for ; Wed, 3 Apr 2019 17:13:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 554331B490; Wed, 3 Apr 2019 17:13:55 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 7F4D71B46A for ; Wed, 3 Apr 2019 17:13:53 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2019 08:13:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,304,1549958400"; d="scan'208";a="128331600" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.35]) by orsmga007.jf.intel.com with SMTP; 03 Apr 2019 08:13:50 -0700 Received: by (sSMTP sendmail emulation); Wed, 03 Apr 2019 16:13:49 +0100 Date: Wed, 3 Apr 2019 16:13:49 +0100 From: Bruce Richardson To: "Wiles, Keith" Cc: "dev@dpdk.org" Message-ID: <20190403151349.GA1325@bricha3-MOBL.ger.corp.intel.com> References: <20190403144505.46234-1-bruce.richardson@intel.com> <5F7D9EB2-AD8D-475B-852C-D8B25475F25C@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <5F7D9EB2-AD8D-475B-852C-D8B25475F25C@intel.com> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH 0/5] clean up snprintf use for string copying 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" Message-ID: <20190403151349.9IyQ0HEYExsfh5XvDPE9Yt6yHoJIqzI7btd3FTEcreo@z> On Wed, Apr 03, 2019 at 03:57:49PM +0100, Wiles, Keith wrote: > > > > On Apr 3, 2019, at 9:45 AM, Bruce Richardson wrote: > > > > There are quite a few instances remaining in DPDK where snprintf is being > > used for string copying. These were not being picked up by our existing > > coccinelle script, but that can be fixed by editing the script and running > > it against our code. In the process a bug was found and fixed in the > > bonding pmd, where we were incorrectly specifiying the buffer length > > parameter to snprintf. > > > > The actual replacement was done in two phases - first replacing all > > instances where only the snprintf line in question needed changing, then > > fixing the other instances where we also needed to add in the header > > include. [Using two stages allowed the header addition to be automated too, > > since we had a list of files where every one needed the header inclusion] > > > > > > Bruce Richardson (5): > > net/bonding: fix buffer length when printing strings > > devtools/cocci: make strlcpy replacement smarter > > devtools/cocci: create safer version of strlcpy script > > replace snprintf with strlcpy without adding extra include > > replace snprintf with strlcpy > > > > Should we not be testing the return values from strlcpy and snprintf, which means we need to create a macro or inline function. We could use a macro and only enable with DEBUG support if we think performance or code size if a problem. > Yes, I think in some/many cases we should be checking the return value, but unfortunately I don't think it's the case that we always should or should not do so. In some cases, truncation is fine. Therefore, I don't think an automated solution can work here, and I don't see much point in wrapping any of these functions in macros, since the action to take on truncation probably varies from place to place. > I am surprised none of the tools are catching these types of problems. > Yes. It would be useful to have a tool to flag this, so we can see under what circumstances it may be a problem. > Not to make Bruce do that change for this patch, but we need to look at it for a later patch IMO. > Phew! :-)