That could work, Keith. However, I would suggest we make use of the gcc "deprecated" function attribute in 1.8 to flag it for future removal in a subsequent release. [Ref: https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html]. That's what the attribute is there for.
From: Wiles, Roger Keith [mailto:keith.wi...@windriver.com] Sent: Monday, June 23, 2014 3:31 PM To: Rogers, Gerald Cc: Richardson, Bruce; Stephen Hemminger; dev at 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. 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-boun...@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