* [dpdk-dev] Why rte_snprintf at all?
@ 2014-06-23 17:16 Stephen Hemminger
2014-06-23 22:18 ` Richardson, Bruce
0 siblings, 1 reply; 8+ messages in thread
From: Stephen Hemminger @ 2014-06-23 17:16 UTC (permalink / raw)
To: dev
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] Why rte_snprintf at all?
2014-06-23 17:16 [dpdk-dev] Why rte_snprintf at all? Stephen Hemminger
@ 2014-06-23 22:18 ` Richardson, Bruce
2014-06-23 22:25 ` Rogers, Gerald
0 siblings, 1 reply; 8+ messages in thread
From: Richardson, Bruce @ 2014-06-23 22:18 UTC (permalink / raw)
To: Stephen Hemminger, dev
> -----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
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] Why rte_snprintf at all?
2014-06-23 22:18 ` Richardson, Bruce
@ 2014-06-23 22:25 ` Rogers, Gerald
2014-06-23 22:31 ` Wiles, Roger Keith
0 siblings, 1 reply; 8+ messages in thread
From: Rogers, Gerald @ 2014-06-23 22:25 UTC (permalink / raw)
To: Richardson, Bruce, Stephen Hemminger, dev
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>
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
>> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] Why rte_snprintf at all?
2014-06-23 22:25 ` Rogers, Gerald
@ 2014-06-23 22:31 ` Wiles, Roger Keith
2014-06-23 22:34 ` Richardson, Bruce
0 siblings, 1 reply; 8+ messages in thread
From: Wiles, Roger Keith @ 2014-06-23 22:31 UTC (permalink / raw)
To: ROGERS, GERALD; +Cc: dev
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] Why rte_snprintf at all?
2014-06-23 22:31 ` Wiles, Roger Keith
@ 2014-06-23 22:34 ` Richardson, Bruce
2014-06-23 22:46 ` Wiles, Roger Keith
0 siblings, 1 reply; 8+ messages in thread
From: Richardson, Bruce @ 2014-06-23 22:34 UTC (permalink / raw)
To: Wiles, Roger Keith (Wind River), Rogers, Gerald; +Cc: dev
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] Why rte_snprintf at all?
2014-06-23 22:34 ` Richardson, Bruce
@ 2014-06-23 22:46 ` Wiles, Roger Keith
2014-06-23 22:53 ` Richardson, Bruce
0 siblings, 1 reply; 8+ messages in thread
From: Wiles, Roger Keith @ 2014-06-23 22:46 UTC (permalink / raw)
To: RICHARDSON, BRUCE; +Cc: dev
Bruce,
Will the deprecated attribute stop the build as warns are converted to errors? Having warns as errors is a good idea IMO, as some warns will cause a problem in execution sometimes or portability.
One suggestion is we can ifdef out the code, but also place the deprecated attribute on the function. Then the #else side of the ifdef is the #define to use snprintf. This way if they enable the ifdef they must live with the problem of deprecation later. Does 1.7 not support the deprecated attribute, maybe that was your point. :-)
I see a lot of code using rte_snprintf and I hate to change all of the code, but it is a simple find/replace sed script.
It is up to you guys I was just suggesting a simple fix for this release instead of the next release.
Thanks
Keith
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:34 PM, Richardson, Bruce <bruce.richardson@intel.com<mailto:bruce.richardson@intel.com>> wrote:
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<mailto: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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] Why rte_snprintf at all?
2014-06-23 22:46 ` Wiles, Roger Keith
@ 2014-06-23 22:53 ` Richardson, Bruce
2014-06-24 9:22 ` Thomas Monjalon
0 siblings, 1 reply; 8+ messages in thread
From: Richardson, Bruce @ 2014-06-23 22:53 UTC (permalink / raw)
To: Wiles, Roger Keith (Wind River); +Cc: dev
Hi Keith,
Will the deprecation warnings stop the build? I would assume so, yes. That would serve as incentive for doing a search-replace to remove the deprecated function. J
As for the #define, it's a quick fix, except that we end up having to keep it forever as the code using the function will never get changed to use rte_snprintf. Given it's just a one-line macro, it's probably not a big deal in this case, but I'd rather see us take the approach that after something has been flagged as deprecated for a certain amount of time e.g. 1 to 2 full release cycles, it is removed completely and deleted. Otherwise I worry about us having to maintain a bunch of stuff for legacy reasons, that really should be got rid of. We should not just remove something completely in a single release, but I think we need to have a way to remove things completely once the user has been given sufficient warning.
Regards,
/Bruce
From: Wiles, Roger Keith [mailto:keith.wiles@windriver.com]
Sent: Monday, June 23, 2014 3:46 PM
To: Richardson, Bruce
Cc: Rogers, Gerald; Stephen Hemminger; dev@dpdk.org
Subject: Re: [dpdk-dev] Why rte_snprintf at all?
Bruce,
Will the deprecated attribute stop the build as warns are converted to errors? Having warns as errors is a good idea IMO, as some warns will cause a problem in execution sometimes or portability.
One suggestion is we can ifdef out the code, but also place the deprecated attribute on the function. Then the #else side of the ifdef is the #define to use snprintf. This way if they enable the ifdef they must live with the problem of deprecation later. Does 1.7 not support the deprecated attribute, maybe that was your point. :-)
I see a lot of code using rte_snprintf and I hate to change all of the code, but it is a simple find/replace sed script.
It is up to you guys I was just suggesting a simple fix for this release instead of the next release.
Thanks
Keith
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:34 PM, Richardson, Bruce <bruce.richardson@intel.com<mailto:bruce.richardson@intel.com>> wrote:
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<mailto: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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] Why rte_snprintf at all?
2014-06-23 22:53 ` Richardson, Bruce
@ 2014-06-24 9:22 ` Thomas Monjalon
0 siblings, 0 replies; 8+ messages in thread
From: Thomas Monjalon @ 2014-06-24 9:22 UTC (permalink / raw)
To: Richardson, Bruce; +Cc: dev
2014-06-23 22:53, Richardson, Bruce:
> As for the #define, it's a quick fix, except that we end up having to keep
> it forever as the code using the function will never get changed to use
> rte_snprintf. Given it's just a one-line macro, it's probably not a big
> deal in this case, but I'd rather see us take the approach that after
> something has been flagged as deprecated for a certain amount of time e.g.
> 1 to 2 full release cycles, it is removed completely and deleted. Otherwise
> I worry about us having to maintain a bunch of stuff for legacy reasons,
> that really should be got rid of. We should not just remove something
> completely in a single release, but I think we need to have a way to remove
> things completely once the user has been given sufficient warning.
I agree.
--
Thomas
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-06-24 9:21 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-23 17:16 [dpdk-dev] Why rte_snprintf at all? 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
2014-06-23 22:46 ` Wiles, Roger Keith
2014-06-23 22:53 ` Richardson, Bruce
2014-06-24 9:22 ` Thomas Monjalon
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).