[llvm-bugs] [Bug 48460] New: Prefer a warning for when VLAs declared on stack

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Dec 9 09:36:27 PST 2020


https://bugs.llvm.org/show_bug.cgi?id=48460

            Bug ID: 48460
           Summary: Prefer a warning for when VLAs declared on stack
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C18
          Assignee: unassignedclangbugs at nondot.org
          Reporter: svoboda at cert.org
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

The Clang docs (https://clang.llvm.org/docs/DiagnosticsReference.html#wvla)
define the "-Wvla" flag to do the following:

    Also controls -Wvla-extension.
    warning: variable length array used

    Warn if a variable-length array is used in the code. -Wno-vla prevents the
-Wpedantic warning of the variable-length array.

The -Wvla flag causes both GCC 10 and Clang 12 to holler about this declaration
having a VLA:

  void func1(int n, int array[n]);

This happens even if func1 is called with a regular array or an int pointer.
Whether you consider 'array' to be a VLA or not depends on how you interpret
ISO C17 6.7.6.3p4.  A colleague called the declaration of array a "heisen-VLA"
on the grounds that array may be cast to a VLA before being immediately cast to
an int pointer.

Clang 12 also hollers about this line, but GCC 10 doesn't:

  void func2(int array[*]);

ISO C17 6.7.6.3p4 is pretty clear that an array declared this way is indeed a
VLA.

But both code examples use VLAs only as an actual parameter argument type. The
main hazard of VLAs is being declared as a stack variable with an unsecured
dimension, where they could potentially exhaust your stack.

Most experts on VLAs would suggest that casting something to a VLA is not a
problem per se, and the real danger of VLAs is declaring a VLA on the stack
(because of the potential for stack exhaustion).  However, neither GCC nor
Clang seem to have a warning to detect VLA stack declarations. This would be a
useful feature, as either a replacement for -Wvla's current behavior, or for a
new warning flag.

    void func1(int n, int array[n]) { /* ok, no warning */
      int array2[n];     /* bad, VLA on stack, warn! */
      int (*array3)[n];  /* ok, no VLA on stack, so no warning */
    }

Finally, declaring a function argument type as a VLA with an explicit
(non-compile-time) array bounds can improve software security, as a VLA bounds
conveys useful semantic information to programmers. Also a VLA bounds can be
checked by the compiler or a static-analysis tool. At CERT, we call such an
array a "conformant array". For more background, see CERT guideline:

  API05-C. Use conformant array parameters
  https://wiki.sei.cmu.edu/confluence/x/n9UxBQ


I have also submitted a similar bug report to GCC, it is here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201209/756149e8/attachment.html>


More information about the llvm-bugs mailing list