<div dir="ltr"><div id="gmail-:mi" class="gmail-a3s gmail-aXjCH"><div lang="EN-US"><div>Hi Michael, Johannes,
<p class="MsoNormal"><br></p><p class="MsoNormal">I'm creating a new thread since my question would be slightly out-of-topic in the original discussion about function attributes:</p>
<p class="MsoNormal"><a href="http://lists.llvm.org/pipermail/llvm-dev/2020-April/141312.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2020-April/141312.html</a></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">If my reading of the C standard is correct, it is UB to redefine libc functions: "If the program declares or defines an identifier 
in a context in which it is reserved (other than as allowed by 7.1.4), 
or defines a reserved identifier as a macro name, the behavior is 
undefined." (<a href="http://port70.net/~nsz/c/c11/n1570.html#7.1.3p2" target="_blank">http://port70.net/~nsz/c/c11/n1570.html#7.1.3p2</a>)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Michael mentioned this in the original thread:</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">> Frontends are supposed to add a "nobuiltin" 
attribute to functions that do not correspond to the semantics of the C 
library function with the same name.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I don't think it was implied that the frontend can argue about the semantics of a function, was it?
</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">There is a "-fno-builtin-<value> family of 
clang CLI options that forbid the compiler to convert libc calls into 
intrinsics. Is it correct to say that the only way for the user
 to define their `memcpy` and avoid UB is to pass "-fno-builtin-memcpy" 
to the compiler?</p><p class="MsoNormal"><br></p><p class="MsoNormal">Thanks,</p><p class="MsoNormal">Alexey<br></p></div></div></div></div>