The difficulty with a testcase like
struct { struct A { int b[1]; } a[5]; } x;
x.a[i].b[j]
is that b is not considered an array at struct end since one of my
recent changes to array_at_struct_end (basically it disallows having
a flex array as the last member of an array).
It would still stand for non-array components with variable offset
but you can't create C testcases for that.
So yes, for the specific case within the array_at_struct_end_p condition
get_addr_base_and_unit_offset is enough. IIRC the conditon was
a bit more than just get_addr_base_and_unit_offset. up_bound !=
INTEGER_CST for example. So make the above
void foo (int n, int i)
{
struct { struct A { int b[n]; } a[5]; } x;
return x.a[i].b[PTRDIFF_MAX/2];
}
with appropriately adjusted constant. Does that give you the testcase
you want?
Thank you for the test case. It is diagnosed the same way
irrespective of which of the two functions is used so it serves
to confirm my understanding that the only difference between
the two functions is bits vs bytes.
Unless you have another test case that does demonstrate that
get_ref_base_and_extent is necessary/helpful, is the last patch
okay to commit?
(Again, to be clear, I'm happy to change or enhance the patch if
I can verify that the change handles cases that the current patch
misses.)
As of "it works, catches corner-cases, ..." - yes, it does, but it
adds code that needs to be maintained, may contain bugs, is
executed even for valid code.
Understood. I don't claim the enhancement is free of any cost
whatsoever. But it is teeny by most standards and it doesn't
detect just excessively large indices but also negative indices
into last member arrays (bug 68325) and out-of-bounds indices
(bug 82583). The "excessively large" part does come largely
for free with the other checks.
Martin