Re: [RFC 10/35] eal: introduce RTE_DECONST macro

[Bruce Richardson <bruce.richardson@intel.com>]

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 you could help me to remove it.
> 
> My opinion is that using a macro like this is cleaner than doing a
> discreet cast that nobody, because it is explicit. The const qualifier
> is not only for the compiler, but also for people reading the code.
> 
> In this case, the objective is to be able to do the following:
> 
> uint32_t rte_mempool_obj_iter(struct rte_mempool *mp,
>        rte_mempool_obj_cb_t *obj_cb, void *obj_cb_arg)
> {
> 	/* call a function on all objects of a mempool */
> }
> 
> static void
> mempool_obj_audit(struct rte_mempool *mp,
> 	__rte_unused void *opaque, void *obj, __rte_unused unsigned idx)
> {
> 	/* do some check on one mempool object */
> }
> 
> 
> void rte_mempool_audit(const struct rte_mempool *mp)
> {
> 	/* iterate objects in mempool using rte_mempool_obj_iter() */
> }
> 
> 
> In the public API:
> 
> - rte_mempool_obj_iter() has the proper prototype: this function
>   can be used to make rw access to the mempool
> - rte_mempool_audit() has the proper public prototype: this function
>   won't modify the mempool
> 
> Internally:
> - we use a deconst to be able to make use of rte_mempool_obj_iter(),
>   but we call a static function that won't modify the mempool.
> 
> Note that this kind of macro is also used in projects like FreeBSD:
> http://fxr.watson.org/fxr/ident?i=__DECONST
> 
> You can also find many examples in Linux kernel where const qualifier
> is silently dropped. For instance, you can grep the following in Linux:
>  "git grep 'iov_base = (void \*)'"
> 
> 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. Also, I'd see having the function itself be a wrapper around a
macro as a better alternative too, assuming such a construction is possible.

/Bruce