Re: RFA: new pass to warn on questionable uses of alloca() and VLAs

[Martin Sebor <msebor at gmail dot com>]

> How does this look?

I think it's 99% there.  You've addressed all of my comments so
far -- thanks for that and for being so patient.  I realize it
would be a lot more efficient to get all the feedback (or as much
of it as possible) up front.  Unfortunately, some things don't get
noticed until round 2 or 3 (or even 4).  Please take this in lieu
of an apology for not spotting the issues below until now(*).

For this code:

  void f (void*);

  void g (int n)
  {
    int a [n];
    f (a);
  }

-Wvla-larger-than=32 prints:

  warning: argument to variable-length array may be too large
  note: limit is 32 bytes, but argument may be 18446744073709551612

An int argument cannot be that large.  I suspect the printed value
is actually the size of the VLA in bytes when N is -1, truncated
to size_t, rather than the value of the VLA bound.  To avoid
confusion the note should be corrected to say something like:

  note: limit is 32 bytes, but the variable-length array may be
  as large as 18446744073709551612

Also, the checker prints false positives for code like:

  void f (void*);

  void g (unsigned x, int *y)
  {
    if (1000 < x) return;

    while (*y) {
      char a [x];
      f (a);
    }
  }

With -Wvla-larger-than=1000 and greater it prints:

  warning: unbounded use of variable-length array

(Same thing with alloca).  There should be no warning for VLAs,
and for alloca, the warning should say "use of variable-length
array within a loop."  The VRP dump suggests the range information
is available within the loop.  Is the get_range_info() function
not returning the corresponding bounds?

Martin

[*] If you want to get me back I invite you (with a bit of
selfishness ;-) to review my -Wformat-length patch.