Re: A question about detecting array bounds for case Warray-bounds-3.c

[Matthew Gretton-Dann <matthew dot gretton-dann at arm dot com>]

On 26/09/11 10:03, Jonathan Wakely wrote:
> On 26 September 2011 08:13, Jiangning Liu wrote:
> > PING...
> >
> > > -----Original Message-----
> > > From: Jiangning Liu [mailto:jiangning.liu@arm.com]
> > > Sent: Thursday, September 22, 2011 10:19 AM
> > > To: gcc@gcc.gnu.org
> > > Cc: 'jakub@gcc.gnu.org'; 'mueller@gcc.gnu.org'; 'rguenth@gcc.gnu.org';
> > > Matthew Gretton-Dann
> > > Subject: A question about detecting array bounds for case Warray-
> > > bounds-3.c
> > >
> > > Hi,
> > >
> > > For case gcc/testsuite/gcc.dg/Warray-bounds-3.c, obviously it is an
> > > invalid C program, because the last iterations of all the loops cause
> > > the access of arrays is beyond the max size of corresponding array
> > > declarations. The condition of checking upper bound should be "<"
> > > rather than "<=".
>
> Which loops are you referring to?
>
>    struct iovec iov[43];
> ...
>    for (; cnt<= 40; ++cnt)
>      {
>        iov[2 + cnt].iov_base =  (void *) (time->am_pm[cnt - 38] ?: "");
>        iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
>      }
>
> What's wrong with that?  The last element accessed is iov[42] which is ok.

This isn't about access to iov - but rather access to the arrays in 
struct S *time:

struct S
{
  const char *abday[7];
  const char *day[7];
  const char *abmon[12];
  const char *mon[12];
  const char *am_pm[2];
};

...

  for (cnt = 0; cnt <= 7; ++cnt)
    {
      iov[2 + cnt].iov_base = (void *) (time->abday[cnt] ?: "");
      iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
    }

The last iteration (cnt == 7) will dereference time->abday[7] which is 
one past the end of the array.

As far as I understand it -Warray-bounds should be emitting a warning 
for this case, but PR31227 seemed to be about removing these warnings.

The PR comments do not explain why the array accesses are valid and I'm 
hoping someone can shed some light on the situation - what are we missing?

Thanks,

Matt

--
Matthew Gretton-Dann
Principal Engineer, PD Software - Tools, ARM Ltd