=?utf-8?q?Donát?= Nagy <donat.n...@ericsson.com>,
=?utf-8?q?Donát?= Nagy <donat.n...@ericsson.com>,
=?utf-8?q?Donát?= Nagy <donat.n...@ericsson.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/78...@github.com>
================
@@ -124,3 +124,25 @@ int assumingConverted2(struct foo f, int arg) {
// expected-note@-2 {{Access of 'array' at negative byte offset}}
return a + b + c;
}
+
+int assumingPlainOffset(struct foo f, int arg) {
+ // This TC is intended to check the corner case that the checker prints the
+ // shorter "offset" instead of "byte offset" when it's irrelevant that the
+ // offset is measured in bytes.
+
+ // expected-note@+2 {{Assuming 'arg' is < 2}}
+ // expected-note@+1 {{Taking false branch}}
+ if (arg >= 2)
+ return 0;
+
+ int b = ((int*)(f.b))[arg];
+ // expected-note@-1 {{Assuming byte offset is non-negative and less than 5,
the extent of 'f.b'}}
+ // FIXME: this should be {{Assuming offset is non-negative}}
+ // but the current simplification algorithm doesn't realize that arg <= 1
+ // implies that the byte offset arg*4 will be less than 5.
----------------
NagyDonat wrote:
Also note that currently the checker only verifies that _(byte offset to first
byte of accessed element) < (extent of memory region in bytes)_; so e.g. it
would accept "`char b[5]; ((int*)b)[1] = 123;`" despite the fact that (assuming
4-bit `int`) this writes 3 bytes after the end of the array `b`.
This issue seems to be mostly theoretical (this sort of low-level memory abuse
should be very rare), but I'll try to ensure that the checker handles it
correctly.
https://github.com/llvm/llvm-project/pull/78315
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
