From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jennifer Herbert Subject: Re: [PATCH 2/7] libxc: Use const pointer in local_file_dump() Date: Tue, 7 Jul 2015 13:16:03 +0100 Message-ID: <559BC303.5030508@citrix.com> References: <1435772232-39085-1-git-send-email-Jennifer.Herbert@citrix.com> <1435772232-39085-3-git-send-email-Jennifer.Herbert@citrix.com> <21910.43476.413848.221992@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21910.43476.413848.221992@mariner.uk.xensource.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: Ian Jackson Cc: stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/07/15 16:27, Ian Jackson wrote: > Jennifer Herbert writes ("[Xen-devel] [PATCH 2/7] libxc: Use const pointer in local_file_dump()"): >> By adding the const keyword, it is clearer to people and static analysis >> tools that no changes to the data are to be made. > Would it be wrong for a future patch to add a field to dump_args which > gets modified ? AFAICT the answer is `no'. So I don't understand why > it ought to be const. > > Does your Coverity instance complain about every instance where a > struct exists which is not marked const but which could be ? Coverity see da->fd being passed to local_file_dump, as a modifiable entity and concludes this function may be overwriting this, and end up leaking the handle. It wouldn't be wrong to modify a new field, I just hadn't considered that likely. Since maybe it is, I'll just mark as false positive. -jenny