[clang] [analyzer] Bring unix.cstring.UninitializedRead checker out of alpha (PR #196292)

[Balázs Benics via cfe-commits]

================
@@ -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