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

[David Chisnall via Phabricator via llvm-commits]

theraven added a comment.

We don't have anything documenting the usage of reserved identifiers.  The C standard reserves identifiers that begin with a double underscore or with an underscore or a capital as reserved for the 'implementation' but assumes that the compiler and library are a single blob.  GCC has a documented policy that double-underscore identifiers are reserved for the compiler and underscore-capital identifiers are reserved for the library (but glibc doesn't follow it, so ended up with `__block` being used as an identifier in `unistd.h`, which broke many things for a long time).  Do we want to have a stricter policy, for example that the only identifiers that we use in public headers that are not standard symbols are `__LLVM_LIBC_{FOO}` for macros and `__llvm_libc_foo` for other identifiers?



================
Comment at: libc/docs/header_generation.md:9
+problems in llvm-libc, we use a header generation mechanism. The mechanism is
+driven by a *header configuration language*.
+
----------------
I'm not sure I understand how this will work.  For existing code, it's common to have to do things like `#define` or `#undef` macros like `_GNU_SOURCE` for a single compilation unit before including libc headers.  There are some annoying differences in philosophy between the header exports: most libc implementations export all interfaces but provide a mechanism for hiding non-standard (or later-standard) ones from portable code, glibc exports only standard functions (though I don't recall which set of standards) and requires feature macros to expose others.  Code that works with glibc and other libc implementations ends up jumping through hoops to support both models.  Are we adding a third mechanism?  Does this work for projects that want to use only standard interfaces in most compilation units but some non-standard extensions in their platform abstraction layer?


================
Comment at: libc/docs/header_generation.md:21
+2. Replace the line on which a command occurs with some other text as directed
+by the command. The replacment text can span multiple lines.
+
----------------
This sounds like you will end up with only one set of headers per configuration, so you lose the ability to have different projects using the same generated headers but enforcing different sets of standards compliance in their use of the interfaces.


================
Comment at: libc/docs/implementation_standard.md:79
+a post build step. For example, for the `round` function, one can use `objcopy`
+to add an alias symbol as follows:
+
----------------
There are a few things that are unclear to me in this description:

1. How do we express the standards to which an entrypoint conforms?  For example, a function defined in C11 or POSIX2008?
2. How do we differentiate between things that we want to be preemptible versus things that we don't?  If we want to call the preemptible version of a symbol in other libc code, will we have the `::foo` symbol visible at library build time?
2. How are we exposing information for building subsets of the implementation that avoid dependencies on certain platform features?  For example, a CloudABI-compatible mode that does not provide (or consume) any functions that touch the global namespace.


================
Comment at: libc/include/ctype.h:14
+extern "C" {
+#endif
+
----------------
BSD libcs include a `cdefs.h` that provides macros such as `__BEGIN_DECLS` and `__END_DECLS` wrapping this kind of pattern, and `__restrict` for language keywords that should not be in headers in certain versions of the standard.  It looks as if `__support/common.h` is the equivalent - we should probably have an explicit rule that this header is included first in all libc headers and provide sensible helpers there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67867