Hi Chandler,<p>I should have clarified that the comments I was referring to were on this bug: <a href="https:&#x2F;&#x2F;llvm.org&#x2F;bugs&#x2F;show_bug.cgi?id=11763" rel="nofollow">https:&#x2F;&#x2F;llvm.org&#x2F;bugs&#x2F;show_bug.cgi?id=11763</a><p>I was surprised to see: &quot;I don&#x27;t think it&#x27;s really worth warning about, considering I don&#x27;t know of any real-world implementation where it doesn&#x27;t work.&quot;<p>That sounds a lot like someone knowingly writing UB in a C program because no compiler they know of breaks the intended behavior.  I doubt any memcpy() has ever guaranteed in any kind of official way that overlapping regions are ok, even if it has historically worked in practice.<p>I mean I&#x27;m sure it&#x27;ll get fixed now, I was just surprised to see this kind of reasoning coming from someone who I presumes works on the compiler.<p>btw. I&#x27;m pretty sure I heard that glibc broke this behavior sometime recently.  There&#x27;s a new memcpy() symbol in glibc these days with a different symbol version that no longer provides correct behavior in the case of overlapping memory regions.  This is all second-hand from some other people I was working with, but if I got their meaning correctly I think this issue will actually have relatively widespread impact.