[Bug c/98217] Prefer a warning for when VLAs declared on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217 --- Comment #9 from David Svoboda --- The more I think about it, the more I want to see two -W warnings...one to flag VLA declarations on the stack, and another to see *any* use of VLAs, even if in something as harmless as a conformant array. The latter flag is simply for platforms (like C++) that does not support VLAs. I am less concerned about codebases that have a "no VLAs" rule. They have the same problem we do of understanding what chat constitutes a VLA, and they would benefit the most from well-defined, precise -W warnings.
[Bug c/98217] Prefer a warning for when VLAs declared on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217 --- Comment #5 from David Svoboda --- Oops, the Clang bug entry is really here: https://bugs.llvm.org/show_bug.cgi?id=48460
[Bug c/98217] Prefer a warning for when VLAs declared on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217 --- Comment #4 from David Svoboda --- Martin: Thanks. It looks like -Wvla-larger-than=0 is (theoretically) a good way to catch VLA stack declarations. There is still the issue that GCC's -Wvla did not flag use of array[*]. To me that is lower-priority, but is still an issue.
[Bug c/98217] Prefer a warning for when VLAs declared on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217 --- Comment #2 from David Svoboda --- I have also submitted a similar bug report to Clang, it is here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217
[Bug c/98217] Prefer a warning for when VLAs declared on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217
David Svoboda changed:
What|Removed |Added
CC||svoboda at cert dot org
--- Comment #1 from David Svoboda ---
The GCC docs (https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html) define
the "-Wvla" flag to do the following:
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
(This bug report reports the same problem as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85997 but provides a more
comprehensive solution.)
[Bug c/98217] New: Prefer a warning for when VLAs declared on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217 Bug ID: 98217 Summary: Prefer a warning for when VLAs declared on stack Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: svoboda at cert dot org Target Milestone: ---
[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581 --- Comment #8 from David Svoboda --- A clarification: The SSE2 instructions are not new. (20 years old) Their use by the optimizer is (relatively) new. (between 4.8.5 and 4.9.4 from my testing).
[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581 David Svoboda changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from David Svoboda --- Yes, this is an old problem. But being old does not invalidate the problem.
[Bug c/87581] New: Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581
Bug ID: 87581
Summary: Misaligned 16-bit read trap on x86 platform should be
either fixed or documented.
Product: gcc
Version: 4.9.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: svoboda at cert dot org
Target Milestone: ---
Created attachment 44825
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44825=edit
Crashing program
The attached code crashes with a SIGSEGV on GCC 4.9.4 on x86-64:
To crash it, compile with: gcc -O3 -fPIC
The same program does not crash if:
* GCC 4.8.5
* -fPIC is omitted
* -mno-sse2 is provided
* -O2
* the compute() function is prepended with:
__attribute__ ((target("no-sse")))
The crash occurs when the program reads and writes mis-aligned 16-bit values.
This is undefined behavior according to C11 s6.3.2.3p7, however it is widely
believed that x86 and x86-64 support unaligned memory reads and writes.
If GCC still assumes that unaligned memory read/write is safe on x86 & x86-64
they should change this optimization behavior.
But if GCC does NOT assume this, they (and others) need to be more vocal about
this. It needs to be in documentation...anyone who uses -O3 should know about
it.
(An alternative is to take SSE2 alignment requirements out of -O3 and put it
somewhere like -Ofast).
