[cfe-dev] LibC functions redefined by the user

[Michael Kruse via cfe-dev]

This is for (mostly) intended for front-ends of languages that are not
C/C++. In Rust for instance, one can define a function "printf" that
is unrelated with the C library function.

As for Clang, a C/C++/Objective-C frontend, it adheres to the
C/C++/Objectice-C specification where those function names are
reserved. I recommend not to redefine those.

I am not sure what the purpose of the -fno-builtin-* flags are, but I
suggest to avoid them as they are non-standard. For Clang, the only
reason for their existence is probably compatibility with gcc.

Michael

Am Mo., 4. Mai 2020 um 10:01 Uhr schrieb Alexey Zhikhartsev
<alexey.zhikhar at gmail.com>:
>
> Hi Michael, Johannes,
>
>
> I'm creating a new thread since my question would be slightly out-of-topic in the original discussion about function attributes:
>
> http://lists.llvm.org/pipermail/llvm-dev/2020-April/141312.html
>
>
>
> 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." (http://port70.net/~nsz/c/c11/n1570.html#7.1.3p2)
>
>
>
> Michael mentioned this in the original thread:
>
>
>
> > 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.
>
>
>
> I don't think it was implied that the frontend can argue about the semantics of a function, was it?
>
>
>
> 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?
>
>
> Thanks,
>
> Alexey