steakhal wrote: At first glance it has similar problems as the ArrayBound. It's frequently difficult to keep track of the buffer and where it points to, and incidentally trick the engine to believe that it points to outside of the buffer - I speculate.
I looked at some of the samples, and for example: 1) [sqlite3.c](https://codechecker-demo.eastus.cloudapp.azure.com/Default/report-detail?review-status=Unreviewed&review-status=Confirmed%20bug&detection-status=New&detection-status=Reopened&detection-status=Unresolved&is-unique=off&diff-type=New&checker-name=alpha.unix.cstring.UninitializedRead&report-hash=9e2f4c437ef44e9d85e6cada01808a48&report-id=8065933&report-filepath=qtbase%2Fsrc%2F3rdparty%2Fsqlite%2Fsqlite3.c): it's not clear to me if this is a TP, and it wasn't classified. When I looked at the trace, I didn't find it easy to decide myself. It doesn't seem to be actionable to me. 2) [ffmpeg/libavcodec/cinepakenc.c](https://codechecker-demo.eastus.cloudapp.azure.com/Default/report-detail?review-status=Unreviewed&review-status=Confirmed%20bug&detection-status=New&detection-status=Reopened&detection-status=Unresolved&is-unique=off&diff-type=New&checker-name=alpha.unix.cstring.UninitializedRead&report-hash=f63c20f3eeeacd8ad0db2f2564b22cd6&report-id=8062594&report-filepath=ffmpeg%2Flibavcodec%2Fcinepakenc.c) Similar as (1). 3) [vim/src/syntax.c](https://codechecker-demo.eastus.cloudapp.azure.com/Default/report-detail?review-status=Unreviewed&review-status=Confirmed%20bug&detection-status=New&detection-status=Reopened&detection-status=Unresolved&is-unique=off&diff-type=New&checker-name=alpha.unix.cstring.UninitializedRead&report-hash=1fe0c22eeaa0c31c184abf14b09dbf92&report-id=8060099&report-filepath=vim%2Fsrc%2Fsyntax.c): It's somewhat funny in the example that it reports that `char_u buf_chartab[32]` was "'buf_chartab' initialized here" - while in fact it was just declared there without any initialization and that was the point of the report. I think this will be confusing to our users. As a generic note, the error message could/should be probably improved, because right now the ` The first element of the 2nd argument is undefined` is not too helpful. The problem is that it could mean two things in the engine: - The location it refers to was never initialized. (like in example 3) - The location might have been initialized, but we formed an out-of-bounds pointer (such as a pointer to the end of a buffer, aka. 1 past last element), and we pass that to something that will dereference it. -- I find these cases a lot more difficult to decipher in practice. If you all still believe that these issues should not block this move, I could look at the other examples to form a grounded opinion, but right now I'm a bit concerned. https://github.com/llvm/llvm-project/pull/196292 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
