[dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro

2016-03-11 Thread Stephen Hemminger
On Thu, 10 Mar 2016 09:11:52 +0100 Olivier MATZ wrote: > > > I would rather have the mempool_audit code take a non-const argument. > > The macro method sets a bad precedent and will encourage more bad code. > > Plus code checkers are likely to flag any such usage as suspect. > > Doing that woul

[dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro

2016-03-10 Thread Olivier MATZ
Hi Bruce, On 03/10/2016 10:26 AM, Bruce Richardson wrote: > On Thu, Mar 10, 2016 at 09:29:03AM +0100, Olivier MATZ wrote: If you have a better alternative, without duplicating the code, I'll be happy to learn. >>> >>> I really don't like this dropping of const either, but I do see the pr

[dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro

2016-03-10 Thread Olivier MATZ
>> If you have a better alternative, without duplicating the code, >> I'll be happy to learn. > > I really don't like this dropping of const either, but I do see the problem. > I'd nearly rather see two copies of the function than start dropping the const > in such a way. I don't think duplicatin

[dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro

2016-03-10 Thread Bruce Richardson
On Thu, Mar 10, 2016 at 09:29:03AM +0100, Olivier MATZ wrote: > >> If you have a better alternative, without duplicating the code, > >> I'll be happy to learn. > > > > I really don't like this dropping of const either, but I do see the problem. > > I'd nearly rather see two copies of the function

[dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro

2016-03-10 Thread Olivier MATZ
> I would rather have the mempool_audit code take a non-const argument. > The macro method sets a bad precedent and will encourage more bad code. > Plus code checkers are likely to flag any such usage as suspect. Doing that would imply dropping the const qualifier in several functions: - rte_mem

[dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro

2016-03-09 Thread Olivier MATZ
Hi, On 03/09/2016 07:53 PM, Stephen Hemminger wrote: > Can't we just write correct code rather than trying to trick the compiler. Thank you for your comment. This macro is introduced for next commit, I would be happy if you could help me to remove it. My opinion is that using a macro like this i

[dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro

2016-03-09 Thread Bruce Richardson
On Wed, Mar 09, 2016 at 09:47:35PM +0100, Olivier MATZ wrote: > Hi, > > On 03/09/2016 07:53 PM, Stephen Hemminger wrote: > > Can't we just write correct code rather than trying to trick the compiler. > > Thank you for your comment. This macro is introduced for next > commit, I would be happy if y

[dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro

2016-03-09 Thread Olivier Matz
This macro removes the const attribute of a variable. It must be used with care in specific situations. It's better to use this macro instead of a manual cast, as it explicitly shows the intention of the developer. This macro is used in the next commit of the series. Signed-off-by: Olivier Matz

[dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro

2016-03-09 Thread Stephen Hemminger
On Wed, 9 Mar 2016 21:47:35 +0100 Olivier MATZ wrote: > Hi, > > On 03/09/2016 07:53 PM, Stephen Hemminger wrote: > > Can't we just write correct code rather than trying to trick the compiler. > > Thank you for your comment. This macro is introduced for next > commit, I would be happy if you cou

[dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro

2016-03-09 Thread Stephen Hemminger
Can't we just write correct code rather than trying to trick the compiler. On Wed, Mar 9, 2016 at 8:19 AM, Olivier Matz wrote: > This macro removes the const attribute of a variable. It must be used > with care in specific situations. It's better to use this macro instead > of a manual cast, as