From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [RFC 10/35] eal: introduce RTE_DECONST macro
Date: Wed, 9 Mar 2016 13:01:59 -0800
Message-ID: <20160309130159.309e5606@xeon-e3>
References: <1457540381-20274-1-git-send-email-olivier.matz@6wind.com>
 <1457540381-20274-11-git-send-email-olivier.matz@6wind.com>
 <CAOaVG17eXh8B7kPvtWsH6q6q1E0S0kgT+fhAz_6C3k0=5iM40g@mail.gmail.com>
 <56E08BE7.6030906@6wind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <dev@dpdk.org>
To: Olivier MATZ <olivier.matz@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pf0-f169.google.com (mail-pf0-f169.google.com
 [209.85.192.169]) by dpdk.org (Postfix) with ESMTP id 651082BB4
 for <dev@dpdk.org>; Wed,  9 Mar 2016 22:02:35 +0100 (CET)
Received: by mail-pf0-f169.google.com with SMTP id 124so50409865pfg.0
 for <dev@dpdk.org>; Wed, 09 Mar 2016 13:02:35 -0800 (PST)
In-Reply-To: <56E08BE7.6030906@6wind.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Wed, 9 Mar 2016 21:47:35 +0100
Olivier MATZ <olivier.matz@6wind.com> 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 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.