[dpdk-dev] Why rte_snprintf at all?
Wiles, Roger Keith
keith.wiles at windriver.com
Tue Jun 24 00:31:26 CEST 2014
Why not just convert it into a macro and ifdef out the code or remove it. This 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]<http://www.windriver.com/announces/wr30/>
On Jun 23, 2014, at 5:25 PM, Rogers, Gerald <gerald.rogers at intel.com<mailto:gerald.rogers at intel.com>> wrote:
Bruce, Stephen,
It may be a duplicate, but people are likely using it. I would assume
deprecate means don¹t remove, but put in a comment that says please don¹t
use and migrate your code away from it.
Thanks,
Gerald
On 6/23/14, 3:18 PM, "Richardson, Bruce" <bruce.richardson at intel.com<mailto:bruce.richardson at intel.com>>
wrote:
-----Original Message-----
From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
Sent: Monday, June 23, 2014 10:16 AM
To: dev at dpdk.org<mailto:dev at 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
More information about the dev
mailing list