From: Olaf Hering <olaf@aepfle.de>
To: Wei Liu <wei.liu2@citrix.com>
Cc: xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
Jan Beulich <JBeulich@suse.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 08:32:51 +0200 [thread overview]
Message-ID: <20150721063251.GA29487@aepfle.de> (raw)
In-Reply-To: <20150720094537.GZ12455@zion.uk.xensource.com>
On Mon, Jul 20, Wei Liu wrote:
> On Mon, Jul 20, 2015 at 11:16:34AM +0200, Olaf Hering wrote:
> > On Mon, Jul 20, Jan Beulich wrote:
> >
> > > >>> On 19.07.15 at 11:33, <olaf@aepfle.de> wrote:
> > > > [ 198s] block-log.c:549:23: error: array subscript is above array bounds [-Werror=array-bounds]
> > > > [ 198s] if (s->connections[i].id == id)
> > > > [ 198s] ^
> > >
> > > So what makes the compiler right with that complaint? I.e. how does
> > > it know i > 0 here? After all - afaict - s->connected can only be 0 or
> >
> > It has to assume that ->connected can get any value because the input
> > comes from outside the unit.
> >
> > To reduce the patch size "&& i < MAX_CONNECTIONS" could be added.
> >
>
> A smaller patch would be preferable at this stage.
I disagree with that.
What is the longterm goal of that binary?
Will it ever be able to handle more than one connection? If so the loops
have to handle holes in ->connections[], which increases patch size.
If it will ever handle only a single conection, please review and spot
possible errors in my patch.
Olaf
next prev parent reply other threads:[~2015-07-21 6:32 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 [this message]
2015-07-21 6:50 ` Jan Beulich
2015-07-21 7:04 ` Olaf Hering
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=20150721063251.GA29487@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.