================
@@ -2353,6 +2353,40 @@ Check for null pointers being passed as arguments to C
string functions:
return strlen(0); // warn
}
+.. _unix-cstring-UninitializedRead:
+
+unix.cstring.UninitializedRead (C)
+""""""""""""""""""""""""""""""""""
+Check for uninitialized reads from common memory copy/manipulation functions
such as:
+ ``memcpy, mempcpy, memmove, memcmp, strcmp, strncmp, strcpy, strlen, strsep``
and many more.
+
+.. code-block:: c
+
+ void test() {
+ char src[10];
+ char dst[5];
+ memcpy(dst,src,sizeof(dst)); // warn: Bytes string function accesses
uninitialized/garbage values
+ }
+
+Limitations:
+
+ - Due to limitations of the memory modeling in the analyzer, one can likely
+ observe some false-positives of the following kind:
+
+ .. code-block:: c
+
+ void false_positive() {
+ int src[] = {1, 2, 3, 4};
+ int dst[5] = {0};
+ memcpy(dst, src, 4 * sizeof(int)); // false-positive:
+ // The 'src' buffer was correctly initialized, yet we cannot conclude
+ // that since the analyzer could not see a direct initialization of
the
+ // very last byte of the source buffer.
+ }
+
+ More details at the corresponding `GitHub issue
<https://github.com/llvm/llvm-project/issues/43459>`_.
----------------
steakhal wrote:
I was catching up, and wanted to have a look at the public facing docs.
I noticed this example, and it's not clear to me what is the fundamental
limitation in the example.
The analyzer sees the `src: {1,2,3,4}` and creates 4 direct bindings in the
Store. Then we copy 4 integers in `memcpy`. Where is the limitation in the
example?
https://github.com/llvm/llvm-project/pull/196292
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
