Re: [Xen-devel] [PATCH] blktap2: update connection handling to fix build with gcc5

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.07.15 at 09:04, <olaf@xxxxxxxxx> wrote:
> 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.

I can only repeat what I said before - that's not the right perspective
to take. Otherwise code like this

void test(char ptr[3], unsigned idx) {
        unsigned i;

        for(i = 0; i < idx; ++i)
                func(ptr[i]);
}

would need to get warned about too, regardless of whether there
is any caller actually passing other than 0, 1, or 2 for "idx". I.e. the
compiler may guess that there could be something wrong here, but
it certainly can't _know_. Replace the 3 above by 1, and you have
the equivalent of what the patch is about.

> 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.

Again I don't think the structure definition is the issue, but (wrong)
assumptions made on the array index. Or did you spot a place
where the array index is known to be non-zero?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel