[dpdk-dev] [PATCH 1/3] stringfns: remove rte_snprintf

[Richardson, Bruce]

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Tuesday, June 24, 2014 10:54 AM
> To: Richardson, Bruce
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/3] stringfns: remove rte_snprintf
> 
> On Tue, 24 Jun 2014 17:39:52 +0000
> "Richardson, Bruce" <bruce.richardson at intel.com> wrote:
> 
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen
> Hemminger
> > > Sent: Tuesday, June 24, 2014 9:03 AM
> > > To: dev at dpdk.org
> > > Subject: [dpdk-dev] [PATCH 1/3] stringfns: remove rte_snprintf
> > >
> > > The function rte_snprintf serves no useful purpose. It is the
> > > same as snprintf() for all valid inputs. Just remove it and
> > > replace all uses in current code.
> > >
> > > Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
> > >
> >
> > NAK to this as is.
> > Approve of replacing all instance of the rte_snprintf function with the standard
> version in all our code and libraries.
> > However, rather than just removing the function completely, I think we should
> just flag the function as deprecated initially, and then later on look to remove it
> completely.
> >
> > /Bruce
> 
> I want to get it out now rather than some 2 year life cycle.
> The issue was discussed and marking it as deprecated breaks the build.
> Alternate is removing all instances and adding:
> 
> #define rte_snprintf	snprintf
> 
> in header file for user compatiablity.

We can remove it from all our apps and then mark as deprecated and all our code would still build.
An interesting point I'd never thought of is, is it right for us to force user apps to treat all warnings as errors? Perhaps we should also consider removing -Werror from the CFLAGS when using rte.extapp.mk.