https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88889
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- On the other side, I wonder how many real-world bugs can it find if valgrind has this strict behavior, isn't the most common case of bugs where all of the bytes are uninitialized, or none of them are? Do we want to flag char buf[16]; memcpy (buf, "abcd", 4); return memcmp (buf, "defghijk", 8); as error? Depending on how is memcmp expanded or library implemented, it will either read one byte at a time (then it will not be flagged as an error), 4 bytes at a time (also not flagged as an error) or 8 bytes at a time (then it is flagged as an error). So, wonder if valgrind couldn't by default handle comparisons where the first few bytes (in memory ordering) of the compared value are defined and then have some undefined ones by trying to find out if regardless of what value would the undefined bytes the comparison would be non-equal silently and have some extra option to make it emit even those errors at the expense of some false positives. Because, say in the memcmp case, if the first 4 bytes are defined and are not equal to the first bytes of the other value, then it will be non-equal regardless of what the other bytes contain. Now, this should be only done if the comparison is consumed as equality comparison by the conditional jump, if it is >/>=/</<=, then obviously all bytes matter.
