[PATCH] D144889: [C2x] Support <string.h> in freestanding

Mon Feb 27 12:16:08 PST 2023

aaron.ballman added a comment.

In D144889#4156068 <https://reviews.llvm.org/D144889#4156068>, @efriedma wrote:

> Historically, the required functions for a "freestanding" C implementation were very restricted.  Freestanding headers didn't export library functions, just constants and types.

<nods>

> As a practical matter, we actually do need a few functions to support code generation for C even if they don't include any standard library headers.  We expect "freestanding" users to provide the three functions memcpy, memmove, and memset.  Other misc. functions like large integer operations and floating point are provided by compiler-rt.builtins (which is ABI-compatible with libgcc).
>
> Note that we can't easily expand the API surface of compiler-rt.builtins; see https://discourse.llvm.org/t/proposal-split-built-ins-from-the-rest-of-compiler-rt/67978 .

Oof.

>> was that the first one is lowered to a potential library call while the second one is is lowered to a backend implementation that performs the work
>
> The difference is really that the __builtin_* functions are recognized as builtins even if the the user is using -fno-builtin/-ffreestanding.  It doesn't mean we actually have dedicated codegen support.

Ah, that's good to know. Thanks!

>> We do not currently have builtins for memccpy, memset_explicit, or strtok
>
> I'm not sure it makes sense to provide a "freestanding" strtok; it requires global state.

I'm happy to file a CD2 comment to this effect.

In D144889#4156120 <https://reviews.llvm.org/D144889#4156120>, @bcraig wrote:

> A freestanding implementation doesn't necessarily mean that everything is header-only.  It's fine to require linking against a (freestanding) C runtime library.  All header-only is fine too though, if you want to make that work.
>
> Architecturally, I don't feel it is required that Clang be the location of all the freestanding headers for C.  I think that's fine for the C library in the final toolchain to own those headers.  I'm not super familiar with what interface contracts you have between the clang-provided C headers and the C-library provided C headers though.

Okay, so this is potentially ignorance on my part. I was under the impression that folks using freestanding mode did not want any library to be linked in. Are there freestanding libc implementations out there that the user would link in instead that we defer to (same as we defer hosted C standard library interfaces to the CRT)? Basically, do we need to do nothing in Clang to support N2524?

>> I'm not sure it makes sense to provide a "freestanding" strtok; it requires global state.
>
> I agree with this, but the C committee felt otherwise.  C++26 freestanding is most likely including strtok too, to stay consistent with C (the freestanding C library paper is through LWG and awaiting a C++26 plenary vote).  It shouldn't be hard to implement in an OS-independent way, but it will be a low quality implementation with cross-thread races.

FWIW, WG14 is having a second round of CD ballot comments. If you'd like, I'm happy to file a comment asking to remove `strtok` from the required set for freestanding conformance.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144889