From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 8B62A685D for ; Tue, 24 Jun 2014 00:34:49 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 23 Jun 2014 15:29:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,533,1400050800"; d="scan'208,217";a="532929669" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga001.jf.intel.com with ESMTP; 23 Jun 2014 15:34:41 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.31]) by IRSMSX101.ger.corp.intel.com ([163.33.3.153]) with mapi id 14.03.0123.003; Mon, 23 Jun 2014 23:34:39 +0100 From: "Richardson, Bruce" To: "Wiles, Roger Keith (Wind River)" , "Rogers, Gerald" Thread-Topic: [dpdk-dev] Why rte_snprintf at all? Thread-Index: AQHPjwbz0aSJjYvEn0epoNdK+kbjGJt/Q+EQ///xPgCAAAHMAIAAERKw Date: Mon, 23 Jun 2014 22:34:38 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B02CEE1C3A@IRSMSX103.ger.corp.intel.com> References: <20140623101603.54a5d887@nehalam.linuxnetplumber.net> <59AF69C657FD0841A61C55336867B5B02CEE0C0E@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:34:50 -0000 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