From: "Richardson, Bruce" <bruce.richardson@intel.com>
To: "Wiles, Roger Keith (Wind River)" <keith.wiles@windriver.com>,
"Rogers, Gerald" <gerald.rogers@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Why rte_snprintf at all?
Date: Mon, 23 Jun 2014 22:34:38 +0000 [thread overview]
Message-ID: <59AF69C657FD0841A61C55336867B5B02CEE1C3A@IRSMSX103.ger.corp.intel.com> (raw)
In-Reply-To: <AA49F83C-6C0A-45DD-B3D4-5D12BCFA9D49@windriver.com>
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.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. 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@intel.com<mailto:gerald.rogers@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@intel.com<mailto:bruce.richardson@intel.com>>
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<mailto: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
next prev parent reply other threads:[~2014-06-23 22:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-23 17:16 Stephen Hemminger
2014-06-23 22:18 ` Richardson, Bruce
2014-06-23 22:25 ` Rogers, Gerald
2014-06-23 22:31 ` Wiles, Roger Keith
2014-06-23 22:34 ` Richardson, Bruce [this message]
2014-06-23 22:46 ` Wiles, Roger Keith
2014-06-23 22:53 ` Richardson, Bruce
2014-06-24 9:22 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59AF69C657FD0841A61C55336867B5B02CEE1C3A@IRSMSX103.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=gerald.rogers@intel.com \
--cc=keith.wiles@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).