[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