From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id A9D9058DF for ; Tue, 24 Jun 2014 00:53:27 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 23 Jun 2014 15:53:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,533,1400050800"; d="scan'208,217";a="552244258" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga001.fm.intel.com with ESMTP; 23 Jun 2014 15:53:42 -0700 Received: from irsmsx105.ger.corp.intel.com (163.33.3.28) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Jun 2014 23:53:40 +0100 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.31]) by IRSMSX105.ger.corp.intel.com ([169.254.7.76]) with mapi id 14.03.0123.003; Mon, 23 Jun 2014 23:53:40 +0100 From: "Richardson, Bruce" To: "Wiles, Roger Keith (Wind River)" Thread-Topic: [dpdk-dev] Why rte_snprintf at all? Thread-Index: AQHPjwbz0aSJjYvEn0epoNdK+kbjGJt/Q+EQ///xPgCAAAHMAIAAERKw///zEQCAABGXsA== Date: Mon, 23 Jun 2014 22:53:39 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B02CEE1C5C@IRSMSX103.ger.corp.intel.com> References: <20140623101603.54a5d887@nehalam.linuxnetplumber.net> <59AF69C657FD0841A61C55336867B5B02CEE0C0E@IRSMSX103.ger.corp.intel.com> <59AF69C657FD0841A61C55336867B5B02CEE1C3A@IRSMSX103.ger.corp.intel.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Why rte_snprintf at all? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 22:53:29 -0000 Hi Keith, Will the deprecation warnings stop the build? I would assume so, yes. That = would serve as incentive for doing a search-replace to remove the deprecate= d function. J As for the #define, it's a quick fix, except that we end up having to keep = it forever as the code using the function will never get changed to use rte= _snprintf. Given it's just a one-line macro, it's probably not a big deal i= n this case, but I'd rather see us take the approach that after something h= as been flagged as deprecated for a certain amount of time e.g. 1 to 2 full= release cycles, it is removed completely and deleted. Otherwise I worry ab= out us having to maintain a bunch of stuff for legacy reasons, that really = should be got rid of. We should not just remove something completely in a s= ingle release, but I think we need to have a way to remove things completel= y once the user has been given sufficient warning. Regards, /Bruce From: Wiles, Roger Keith [mailto:keith.wiles@windriver.com] Sent: Monday, June 23, 2014 3:46 PM To: Richardson, Bruce Cc: Rogers, Gerald; Stephen Hemminger; dev@dpdk.org Subject: Re: [dpdk-dev] Why rte_snprintf at all? Bruce, Will the deprecated attribute stop the build as warns are converted to erro= rs? Having warns as errors is a good idea IMO, as some warns will cause a p= roblem in execution sometimes or portability. One suggestion is we can ifdef out the code, but also place the deprecated = attribute on the function. Then the #else side of the ifdef is the #define = to use snprintf. This way if they enable the ifdef they must live with the = problem of deprecation later. Does 1.7 not support the deprecated attribute= , maybe that was your point. :-) I see a lot of code using rte_snprintf and I hate to change all of the code= , but it is a simple find/replace sed script. It is up to you guys I was just suggesting a simple fix for this release in= stead of the next release. Thanks Keith Keith Wiles, Principal Technologist with CTO office, Wind River mobile 972-213-5533 [Powering 30 Years of Innovation] On Jun 23, 2014, at 5:34 PM, Richardson, Bruce > wrote: That could work, Keith. However, I would suggest we make use of the gcc "deprecated" function attri= bute in 1.8 to flag it for future removal in a subsequent release. [Ref: ht= tps://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html]. That's what the= attribute is there for. From: Wiles, Roger Keith [mailto:keith.wiles@windriver.com] Sent: Monday, June 23, 2014 3:31 PM To: Rogers, Gerald Cc: Richardson, Bruce; Stephen Hemminger; dev@dpdk.org Subject: Re: [dpdk-dev] Why rte_snprintf at all? Why not just convert it into a macro and ifdef out the code or remove it. T= his way it can we remove later or just kept for some backward compat reason= . #define rte_snprintf snprintf Keith Wiles, Principal Technologist with CTO office, Wind River mobile 972-213-5533 [Powering 30 Years of Innovation] On Jun 23, 2014, at 5:25 PM, Rogers, Gerald > wrote: Bruce, Stephen, It may be a duplicate, but people are likely using it. I would assume deprecate means don=B9t remove, but put in a comment that says please don= =B9t use and migrate your code away from it. Thanks, Gerald On 6/23/14, 3:18 PM, "Richardson, Bruce" > wrote: -----Original Message----- From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger Sent: Monday, June 23, 2014 10:16 AM To: dev@dpdk.org Subject: [dpdk-dev] Why rte_snprintf at all? Why does rte_snprintf exist? It seems like a misunderstanding or broken implementation of snprintf in some other C library. For standard Glibc, I get same result from rte_snprintf and snprintf for all inputs including boundary cases It can indeed probably be deprecated in next release. Any objections? /Bruce