4 ms·
No, Clang cannot guarantee its own memcpy implementation will be used. But it can be aware of which implementation will be used and make specific assumptions ab
by chandlerc1024 10y ago
No, Clang cannot guarantee its own memcpy implementation will be used. But it can be aware of which implementation will be used and make specific assumptions about that implementation in some cases.
The specific cases are when it has a genuine guarantee provided by that implementation vendor that it is OK. In the case discussed on this bug, at least one implementation provides that guarantee (Darwin). The problem is that not all provide it, and further than other parts of LLVM have started assuming that the memcpy more closely matches C semantics. At least something will have to change here, but the C semantics are really relevant at all, or what is "valid C code".
- kazinator 10y agoClang is not a complete implementation without a library, right? Whoever puts Clang together with a library becomes an integrator who provides a language implementation. It's up to that integrator to ensure that the result conforms. Clang could be also used "freestanding". Then the user might be informed: please supply your own memcpy function with such and such characteristics, since generated code needs it. If those characteristics are just those described in ISO C, but the compiler needs something more, then that's a problem between clang and the user.
- chandlerc1024 10y agoEssentially. But I think Clang can actually do better here. The open source project is essentially providing integration with glibc and other libcs and we don't do a reasonable job of being conservative there where we don't know what requirements that layer places upon things like memcpy.