On Tue, Sep 03, 2013 at 11:01:17AM -0500, Meador Inge wrote:
> On 09/03/2013 10:45 AM, Jakub Jelinek wrote:
>
> > On Tue, Sep 03, 2013 at 10:40:16AM -0500, Meador Inge wrote:
> >>> And I fail to see why the testcase should
> >>> not warn. Clearly you have a definition of a here and it doesn't have
> >>> an element
> >>> so the access is out of bounds.
> >>
> >> Not always, 'size_a' can be zero and the warning is worded such that the
> >> out of
> >> bounds access always happens. In fact, changing the code to 'size_a = 0'
> >> still
> >> issues a warning.
> >
> > How would that be different if you had that invalid access in a function
> > and never called the function, or called it only if (0) or similar?
> > We don't do reachability analysis, if any code we warn about can be
> > reachable from main, and still warn about invalid code, this is invalid
> > code, so it is IMHO just fine to warn about it.
>
> True. Perhaps I am getting too caught up in the wording. I thought we
> typically use "may" for warnings that aren't definitive, but in this case
> we use "is" (instead of something like "may be"):
>
> warning: array subscript is above array bounds [-Warray-bounds]
That is only the case for uninit warnings which makes this distinction, no
other warning afaik does something similar.
And, even for uninit, even if you get is used uninitialized warning, it
still may be on dead code, the difference is that if you hit the statement
on which it warns, when it is the "is" variant, it means that you use
there an uninitialized value, while the "may" variant means you can hit it
both with uninitialized or initialized value. If you hit the a[0]
statement, you always invoke undefined behavior, so it shouldn't be a "may".
Jakub
