From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by dpdk.org (Postfix) with ESMTP id EE18A30E for ; Tue, 24 Jun 2014 00:45:58 +0200 (CEST) Received: from ALA-HCB.corp.ad.wrs.com (ala-hcb.corp.ad.wrs.com [147.11.189.41]) by mail.windriver.com (8.14.5/8.14.5) with ESMTP id s5NMkGJX001437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jun 2014 15:46:16 -0700 (PDT) Received: from ALA-MBA.corp.ad.wrs.com ([169.254.2.48]) by ALA-HCB.corp.ad.wrs.com ([147.11.189.41]) with mapi id 14.03.0174.001; Mon, 23 Jun 2014 15:46:16 -0700 From: "Wiles, Roger Keith" To: "RICHARDSON, BRUCE" Thread-Topic: [dpdk-dev] Why rte_snprintf at all? Thread-Index: AQHPjwbgO61bhZd0I0iFEC7fa5JMF5t/uXYAgAABxQCAAAHLgIAAAOYAgAADPgA= Date: Mon, 23 Jun 2014 22:46:14 +0000 Message-ID: References: <20140623101603.54a5d887@nehalam.linuxnetplumber.net> <59AF69C657FD0841A61C55336867B5B02CEE0C0E@IRSMSX103.ger.corp.intel.com> <59AF69C657FD0841A61C55336867B5B02CEE1C3A@IRSMSX103.ger.corp.intel.com> In-Reply-To: <59AF69C657FD0841A61C55336867B5B02CEE1C3A@IRSMSX103.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.25.40.162] MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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:45:59 -0000 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 =93deprecated=94 function a= ttribute in 1.8 to flag it for future removal in a subsequent release. [Ref= : https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html]. That=92s wh= at 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