> An implementation is not bound by the standard in its own use of the standard library functions. The implementation can use a function like memcpy in ways tha

> An implementation is not bound by the standard in its own use of the standard library functions. The implementation can use a function like memcpy in ways that would be formally undefined if they occured in user code; its implementation of memcpy just has to harmonize with that use, so that the intended behavior is ensured. This is because implementations can add their own requirements to areas that the standard leaves undefined. For instance, an implementation can add the requirement to its memcpy that the copy may overlap, if the destination has a lower address. Then, the implementation can generate code which uses memcpy that way, or make internal uses of memcpy from other library functions which use it that way. It's just using its own (possibly not publicly documented) extension. Yes. But right now they do not do that, and it's not their implementation of memcpy they rely on, and they are exactly doing the kind of things they disallow their users to do, so the whole picture is just plain insane. They just call libc memcpy in some cases, and their rational is that "it happens to work". Except nobody is actually sure about that, it might be already buggy on PPC, and the guarantee is not documented anywhere. Completely insane - especially given their very own approach in similar situations. As usual, they are prioritizing "optimizations" over correctness, and lets not even think about defense in depth. It's a brand new level of insanity, even beyond their usual "the standard allows us to do that" excuse, because here it does not even allow that, and it seems that neither do officially all the used implementations! Software engineers must loose the habit of taking all kind of crazy risks that can only lead to marginally faster execution of newly introduced bugs. That does not serve any purpose.