[PATCH] D67867: [libc] Add few docs and implementation of strcpy and strcat.

[Siva Chandra via Phabricator via llvm-commits]

sivachandra added a comment.

In D67867#1691962 <https://reviews.llvm.org/D67867#1691962>, @jyknight wrote:

> The issue really only exists when you refer to object files across standards layers -- e.g., using an object file that exposes the POSIX symbol "open" from an object file implementing ISO C. If you make sure to always strictly-layer the libc, so that ISO C-implementing object files don't use any POSIX-exporting object files, and so on, you won't need to mark anything weak. For the example of "open", you'd have an internal implementation of `open` in its own file, only exposing libc-internal symbols. Then `fopen` (ISO C) can use that safely, without dragging in a definition of the symbol `open`. Separately, the implementation of `open` (POSIX) can be defined in its own file, also based on the internal open.)


This approach is fairly general can be adopted with the existing setup as well. In fact, I can image that irrespective of the approach we take, we will end up with patterns like this.

> Sort of... At the source level, you can keep using namespaces as usual -- you don't need to move the function to the global namespace. E.g., given
> 
>   namespace __llvm_libc {
>   extern "C" __llvm_libc_strcat(...) {
>     ...
>   }
>   }
> 
> 
> the `__llvm_libc_strcat` function is within the namespace `__llvm_libc`, as far as C++ name-resolution semantics are concerned. It's only at a lower level, in the object-file linkage semantics, that it is "as if" it was in the global namespace -- the function has been given the symbol name `__llvm_libc_strcat` instead of a C++ namespace-mangled name.

This approach was also considered. (I missed the `__` prefixes in my considerations of course.)

>> I rather prefer everything in a single LLVM-libc specific namespace. The objcopy step is neatly hidden behind a build rule, so I do not see it as being "complicated" or "confusing". Someone coming in to implement a new function just has to use the build rule and put the code in the namespace.
> 
> I do think it's both complicated and confusing to have build rules invoking objcopy to post-process `.o` files after compilation. If that was //necessary//, it'd be one thing, but since it's not, I'd say the additional complexity is not justified.

This is in subjective territory...

I prefer not to have the repetitiveness of __llvm_libc::__llvm_libc_strcpy or anything similar. One can suggest using a macro to avoid the repetitiveness of course, but I'd rather avoid using a macro at every call site. To me, that seems not pretty and not necessary. I prefer to keep the implementation layer be as much as possible like a normal C++ library. The post-processing is done to make this C++ library be usable as a C library as well.

I agree that, "post-processing using objcopy" does sound complex as it kind of gives a feel of a complex binary surgery. But, what the current proposal is doing is to just add an alias symbol using objcopy. That is neither invasive, nor complex as "post-processing using objcopy" sounds. Moreover, as I have said earlier, developers do not need to deal with objcopy on a regular basis as it is hidden behind a build rule.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67867/new/

https://reviews.llvm.org/D67867