From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [patch 3/3] xen/privcmd: remove const modifier from declaration Date: Mon, 10 Sep 2012 11:43:19 +0100 Message-ID: <504DC447.9010301@citrix.com> References: <20120908095808.GC608@elgon.mountain> <504DC8FE020000780009A190@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <504DC8FE020000780009A190@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk , Andres Lagar-Cavilla , kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org, Dan Carpenter List-Id: xen-devel@lists.xenproject.org On 10/09/12 10:03, Jan Beulich wrote: >>>> On 08.09.12 at 11:58, Dan Carpenter wrote: >> When we use this pointer, we cast away the const modifier and modify the >> data. I think it was an accident to declare it as const. > > NAK - the const is very valid here, as the v2 interface (as opposed > to the v1 one) does _not_ modify this array (or if it does, it's a > bug). This is a guarantee made to user mode, so it should also be > expressed that way in the interface. > > But of course the cast used before this patch isn't right either, as > it indeed inappropriately discards the qualifier. Afaiu this was done > to simplify the internal workings of the code, but I don't think it's > desirable to sacrifice type safety for implementation simplicity. m.arr here isn't const as m is really the V1 structure where m.arr is non-const. David