https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108598
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks for filing this report.
It looks like the tool you're using to collate diagnostics is omitting
important information from the report.
Specifically, if I try the example with Compiler Explorer here:
https://godbolt.org/z/sWon4rqG9
...I see useful information within the execution paths that isn't in the text
you pasted into this BZ report.
In particular, the full report from -fanalyzer shows that:
| 9 | int *arr = alloca(length);
| | ^~~~~~
| | |
| | (1) capacity: 99 bytes
|
[...snip...]
| 20 | arr[length / 2 + 1] = '\0'; // <- false positive here
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (6) out-of-bounds write from byte 200 till
byte 203 but region ends at byte 99
|
The issue is that "arr" is an int *, not a char *, and hence, given a target
where sizeof(int) == 4, each access of arr[x] is a 4-byte access starting at
byte (x * 4). Hence arr[length / 2 + 1] == arr[50], and accessing arr[50] is
accessing bytes 200-203, but the buffer is only 99 bytes in size.
So if I'm reading this right, this is a true positive, so I'm going to mark it
as "RESOLVED INVALID".
PVS Studio also complains about it:
https://godbolt.org/z/hqbKKs6hd
That said, valgrind doesn't seem to complain about this write for some reason:
#include <stdlib.h>
int main(void)
{
int length = 99;
int *arr = alloca(length);
arr[length / 2 + 1] = '\0';
return 0;
}
There's also a missing warning from -Wanalyzer-allocation-size when the alloca
result is assigned to "int *", which I've filed as PR analyzer/108616.
