Hacker News Reader

Comment by Dylan16807 | Hacker News Reader

The compiler is using the ISO language standard to define the behavior of an internal piece. It is then using that piece in the wrong way. It's not generic "not defined" behavior, it is specific C "undefined behavior".

Think of that part of the transformed code as still C for relevant purposes.

View on HN

I want to assure you that the compiler does not exclusively use the ISO language standard to define the behavior of internal components of the implementation.

I'm talking about a specific component named memcpy. Obviously this does not apply to other components.

And even that is only if the bug report is correct.

The compiler is not producing C code that calls memcpy. It is leveraging a specific implementation of a memcpy symbol in a particular system library. The contract between Clang and that system library can include guarantees not provided by any ISO standard.

Then the bug report is wrong, and disregard the second and third posts I made. They depend on the bug report not being wrong.

My first post is generic and not about this particular issue; it's still fine.

The bug report is not wrong. Rather, whether the current behavior is correct depends on the platform.

For example, Darwin's libc offers this contract for memcpy and clang is perfectly within its rights to generate such code (note that the IR it generates is still violating LLVM's contract on the memcpy intrinsic); glibc offers no such contract for memcpy, and so clang's code is nonconformant.

Reply on news.ycombinator.com