From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
xen-devel@lists.xen.org, Wei Liu <wei.liu2@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH] blktap2: update connection handling to fix build with gcc5
Date: Tue, 21 Jul 2015 09:04:56 +0200 [thread overview]
Message-ID: <20150721070456.GA1728@aepfle.de> (raw)
In-Reply-To: <55AE07CA0200007800093792@prv-mh.provo.novell.com>
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
next prev parent reply other threads:[~2015-07-21 7:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-19 9:33 [PATCH] blktap2: update connection handling to fix build with gcc5 Olaf Hering
2015-07-20 9:09 ` Jan Beulich
2015-07-20 9:16 ` Olaf Hering
2015-07-20 9:45 ` Wei Liu
2015-07-21 6:32 ` Olaf Hering
2015-07-21 6:50 ` Jan Beulich
2015-07-21 7:04 ` Olaf Hering [this message]
2015-07-21 7:25 ` Jan Beulich
2015-07-21 8:38 ` Ian Campbell
2015-07-21 9:44 ` George Dunlap
2015-07-20 10:10 ` Jan Beulich
2015-07-20 10:23 ` M A Young
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150721070456.GA1728@aepfle.de \
--to=olaf@aepfle.de \
--cc=JBeulich@suse.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.