From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH] blktap2: update connection handling to fix build with gcc5 Date: Tue, 21 Jul 2015 09:04:56 +0200 Message-ID: <20150721070456.GA1728@aepfle.de> References: <1437298408-23414-1-git-send-email-olaf@aepfle.de> <55ACD6CC0200007800092F33@mail.emea.novell.com> <20150720091634.GA4320@aepfle.de> <20150720094537.GZ12455@zion.uk.xensource.com> <20150721063251.GA29487@aepfle.de> <55AE07CA0200007800093792@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <55AE07CA0200007800093792@prv-mh.provo.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: Ian Jackson , xen-devel@lists.xen.org, Wei Liu , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Tue, Jul 21, Jan Beulich wrote: > But anyway, the primary question remains - isn't what you're seeing > a compiler bug? If yes, that's imo _yet another_ reason for doing a > minimal workaround (if any at all). I dont think its a compiler bug. How should the compiler know that the index variable matches the array size? If the code would modify index and array all inside the same unit it may have a chance to see that it can never be above array_size. But as it stands the pointer comes from outside the unit. One could argue that the struct is defined just inside that unit and it gets passed back in as a void pointer. So an optimistic view on the issue could be: noone knows what "void *p" is all about, so nothing would touch it. But gcc doesnt work that way. Not sure if it should. Olaf