From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Wed, 9 Mar 2016 22:02:35 +0100 (CET) Received: by mail-pf0-f169.google.com with SMTP id 124so50409865pfg.0 for ; Wed, 09 Mar 2016 13:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=OJJieLDJZ4yOcYfWDFEZtAauDp/TIgB65dOCmT7z01E=; b=OlZQ0PlyhAsm8BErdNItjmuhsNbn5Vk43oTRoH4yGr4Oz8QDsA8G1m/UzOO+SiAwRf Xtlp9+0QzAUGqXpvNbCGwNe89UDBSH9YG+jDxLMuLNMazLjTV9t6zD2pjDPel2c0AisD S3LH2yn4gEUj52gHJAZERqlbxlM9nWyDxu+ubrL2Gnftb+d1OTap7U09MKX5IB2DyJkG 2cIoVdhkmunUylvI/Qii3EBvxy/1UGm5xIfF/h2f2pzLswKb0/laBxmhrztxPYORc96x uMY+3rIiThX8kmEmbdxv9RnpupfXCqfdHANTODb7qWgSJ2lWT3YIbmmxZRi4TL+/jnRc Gj4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=OJJieLDJZ4yOcYfWDFEZtAauDp/TIgB65dOCmT7z01E=; b=dl/IYooaGXvwh6ekQM2kW1d+JtoZxAfnRTfMq7o8wy1CAKTLkUhSslaXoPJ7bdvXKX png9yyb7dgGZ6PjYnrOK1YWeqHnFwFqJYj7vlZdZIMNW/YK8724T7X93X2p3706Jj7xR Q4mOy42FSdKfBbOe5i7bW+t8Rjh07lnNo+Y3xGN07pbdzCc27C0bMbicT7nBmnRylcwU 7fKVkkwRjQlqEZlFYlpSf4dHCtlo9p0lGlwd47aZ8oxM1QoJLfuUjfyrjXbiAQloX5sM AaMERBzz0kr6HTl0RDT78XTemq92QDAMy3dmRALXvt2vXZMAesNHhTA64PGcagXn/TYK lPng== X-Gm-Message-State: AD7BkJJiGVsAI3bif+mYfDt/Z1uekNj5hMR41tO2qF9efXEX1dJepnH5HuIp22nQz8QooA== X-Received: by 10.98.65.14 with SMTP id o14mr398843pfa.151.1457557354772; Wed, 09 Mar 2016 13:02:34 -0800 (PST) Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id 79sm289137pfq.65.2016.03.09.13.02.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Mar 2016 13:02:34 -0800 (PST) Date: Wed, 9 Mar 2016 13:01:59 -0800 From: Stephen Hemminger To: Olivier MATZ Message-ID: <20160309130159.309e5606@xeon-e3> In-Reply-To: <56E08BE7.6030906@6wind.com> References: <1457540381-20274-1-git-send-email-olivier.matz@6wind.com> <1457540381-20274-11-git-send-email-olivier.matz@6wind.com> <56E08BE7.6030906@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 21:02:35 -0000 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 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.