Fixing GitHub issue: https://github.com/llvm/llvm-project/issues/55019
Following the previous fix https://reviews.llvm.org/D12571 on issue https://github.com/llvm/llvm-project/issues/23328
The two issues report false memory leaks after calling string-copy APIs with a buffer field in an object as the destination.
The buffer invalidation incorrectly drops the assignment to a heap memory block when no overflow problems happen.
And the pointer of the dropped assignment is declared in the same object of the destination buffer.
The previous fix only considers the memcpy functions whose copy length is available from arguments.
In this issue, the copy length is inferable from the buffer declaration and string literals being copied.
Therefore, I have adjusted the previous fix to reuse the copy length computed before.
Besides, for APIs that never overflow (strsep) or we never know whether they can overflow (std::copy),
new invalidation operations have been introduced to inform CStringChecker::InvalidateBuffer whether or not to
invalidate the super region that encompasses the destination buffer.
I don't think this is the cleanest way to achieve this.
To me, it feels like it might make sense to have distinct invalidation functions for each scenario and mentally share the same overload-set.
Right now, the API looks really complicated: using enum values along with default parameters. Not to speak of how many parameters it accepts.
However, I won't object this time given that it was already pretty bad, and unreadable - so in that sense, it's not much worse this way and it was not the point to improve the quality of the code.