From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: [PATCH 0/5] clean up snprintf use for string copying Date: Wed, 3 Apr 2019 16:13:49 +0100 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=us-ascii Cc: "dev@dpdk.org" To: "Wiles, Keith" Return-path: 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) Content-Disposition: inline In-Reply-To: <5F7D9EB2-AD8D-475B-852C-D8B25475F25C@intel.com> 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 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! :-)