<div dir="ltr"><div>Dear All,</div><div><br></div><div>I have been looking into PR22954 which has been kindly raised by krzystof at <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D22954&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=O5dh4PmkmIqgA51Td6KelAaScScWbARlJpot4_Oeh3g&s=uGkJTIffgnZsrNbx4HXzZae_zcPOJx8S4f5YLWTNx9g&e=">https://llvm.org/bugs/show_bug.cgi?id=22954</a> and being new to this area of Clang I would appreciate any tips on how to fix it.</div><div><br></div><div>To me the root of the issue seems to originate from the CString checker as it performs invalidation of the destination buffer.</div><div>Given the snippet below:</div><div>-----------------</div><div>struct aa { char *s; char data[32];};</div><div>...</div><div>a.s = malloc(nbytes);</div><div>memcpy(a.data, source, len);</div><div>...</div><div>-----------------</div><div>As the CString checker handles the memcpy call, it requests the invalidation of the 'a.data' region. But the invalidation worker seems to consider that the whole memory region of 'a' has to be invalidated. The Malloc checker is not made aware of this causing the false positive.</div><div><br></div><div>It seems a short term fix could be to detect this specific case and have the CString checker notify the Malloc checker that it should stop tracking 'a.s'.</div><div>However this solution would reduce the number of genuine defects detected.</div><div><br></div><div>So I would be grateful if someone could give some hints on how to provide the right solution.</div><div><br></div><div>Regards,</div><div><br></div><div>Pierre Gousseau</div><div>SN Systems - Sony Computer Entertainment</div></div>