[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