[C2x] Support <string.h> in freestanding

[aaron.ballman]

Summary

This implements most of the support for WG14 N2524 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2524.htm), which adds <string.h> to the list of headers required by a freestanding implementation.

We do not currently have builtins for memccpy, memset_explicit, or strtok, so those APIs are not yet exposed via our freestanding string.h. Further, we do not yet implement WG14 N3020 which changes the return type for some of the interfaces in string.h. So this patch does not claim full support for string.h yet (it adds the __STDC_VERSION_STRING_H__ macro but leaves its value as 202300L instead of 202311L as required by the standard).

[efriedma]

Providing this header doesn't do anything useful without an actual implementation; all of these "__builtin" calls just lower to libc calls in the general case. How do you plan to provide implementations?

[aaron.ballman]

In D144889#4155686, @efriedma wrote:

Providing this header doesn't do anything useful without an actual implementation; all of these "__builtin" calls just lower to libc calls in the general case. How do you plan to provide implementations?

I *thought* that the difference between:
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/Builtins.def#L1038
and
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/Builtins.def#L559
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. (This is why I thought we would not be able to support memccpy or strtok -- they were missing the __builtin_ variants.) If the backend is just going to generate a library call that requires an external library when calling a __builtin_, then I agree that there's more here that needs to be done. How do we typically handle it for freestanding functions? Do we implement something in compiler-rt as a fallback, or do we emit LLVM IR for the function implementation, etc?

[efriedma]

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

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 .

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.

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.

[bcraig]

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.

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.

[aaron.ballman]

In 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, @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.

[bcraig]

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?

Well, people want all sorts of things :)

(Gross generalizations coming) The compiler writer view of freestanding that I've heard in the past is that the compiler writer views freestanding as the necessary parts of the library needed to support the language. This is mostly accurate when describing freestanding prior to C++23 and C23. Most of that is either header-only, in libc++abi, or in compiler-rt. This makes testing the compiler a bit easier, as you don't need a full stdlib. That's not a design goal of freestanding post C/C++23 though. It's fine for Clang to provide half of a stdlib for internal testing or integration with other C libraries, so long as the final toolchain has everything.

One challenge for some customers will be that they like to build with -nodefaultlibs, but that's not a deal breaker here, it just means that they would need to manually put their C library on the link line. Alternatively, they could start passing other linker flags, like -nostartfiles instead, but that will be use case dependent. These kinds of hoops have historically been needed because a customer may use a "stock" ARM Clang, but not want to use the libc that came with that toolchain, so the big linker flags would come out to give the user control.

I don't think that Clang-the-compiler needs to do anything to support the new C/C++ freestanding features. The main caveat being that you still need to be able to ensure the provided memcpy gets used instead of a codegenned (possibly vectorized) memcpy, but I think -ffreestanding already forces the compiler to generate calls and not use in-compiler codegen.

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.

That would be much appreciated. I can try to get my INCITS / ISO status squared away so that I can represent that issue at the appropriate meeting.

[bcraig]

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?

Oh, and I forgot GPUs. GPUs do like having everything be header-only, but in my opinion, that's still a requirement / request for C library authors rather than the compiler.

[efriedma]

In 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.

In practice, there are basically three ways people can use clang:

1. A normal operating system target with a "hosted" libc.
2. A baremetal target with an "embedded" libc; basically a stripped down libc which only includes stuff that doesn't require an operating system. What exactly this includes varies; may include some form of "malloc", some "POSIX" APIs, semihosting, etc.
3. A baremetal target with no libc, using custom implementations for everything. This is what we conventionally referred to as "freestanding", and what -ffreestanding implements. The user provides memcpy/memmove/memset, and uses the compiler-provided "builtins" lib if neceessary, but nothing we would traditionally call "libc".

We could just refuse to provide any APIs outside of our conventional notion of "freestanding", I guess, and say users that want a C23 freestanding environment need to find their own mini-libc. Or just provide the header, and say users are responsible for providing implementations, like they currently are for memcpy etc. That doesn't really align with what the committee was hoping for, though...

Maybe eventually we can come up with some way to use implementations provided by LLVM libc, but I'm not sure what exactly that looks like.

[bcraig]

1. A normal operating system target with a "hosted" libc.
2. A baremetal target with an "embedded" libc; basically a stripped down libc which only includes stuff that doesn't require an operating system. What exactly this includes varies; may include some form of "malloc", some "POSIX" APIs, semihosting, etc.
3. A baremetal target with no libc, using custom implementations for everything. This is what we conventionally referred to as "freestanding", and what -ffreestanding implements. The user provides memcpy/memmove/memset, and uses the compiler-provided "builtins" lib if neceessary, but nothing we would traditionally call "libc".

In my committee work, I'm targeting option 2. I think that's what should be considered when talking about freestanding in a standards context.

Option 3 is valuable and should continue to exist, but it is non-conforming pre-C23 and post-C23. The standards don't have any provision for requiring the user to implement mem* functions that the implementation chooses to invoke without the user ever spelling that function call (perhaps because they did char buf[256] = {0} though). Post-C23, it doesn't provide enough. The C library authors will likely need this mode to author the C library itself though. I'll suggest calling this mode something like "nodefaultlibs".

[efriedma]

perhaps because they did char buf[256] = {0} though

Right, we need memcpy and memset to emit reasonable code for struct/array initialization and assignment.

We don't provide any library that includes memcpy/memset/memmove because of a combination of legacy, and that writing well-optimized versions is hard. Ideally, it probably makes sense.

[rsmith]

Do we know what GCC intends to do about this C change? Per their documentation, they intend for GCC to be / eventually become a complete freestanding implementation without need for a separate libc:

GCC aims towards being usable as a conforming freestanding implementation, or as the compiler for a conforming hosted implementation.
GCC does not provide the library facilities required only of hosted implementations, nor yet all the facilities required by C99 of freestanding implementations on all platforms.

(Emphasis mine.) Likely because of GCC's perspective on this, the set of C headers provided by GCC, Clang, ICC, etc. has included the complete list of freestanding headers and more or less no others, with some libc implementations providing the full set and some providing just the non-freestanding ones. If we're moving away from that, we'll presumably need a new agreement between compiler folks and libc folks about which headers are provided by whom (and I expect it'll be "compilers provide what the C standard said before this change to freestanding and we pretend the change never happened").

[jyknight]

In D144889#4156974, @rsmith wrote:

Likely because of GCC's perspective on this, the set of C headers provided by GCC, Clang, ICC, etc. has included the complete list of freestanding headers and more or less no others, with some libc implementations providing the full set and some providing just the non-freestanding ones. If we're moving away from that, we'll presumably need a new agreement between compiler folks and libc folks about which headers are provided by whom (and I expect it'll be "compilers provide what the C standard said before this change to freestanding and we pretend the change never happened").

Yeah...this seems like a pretty big divergence from the historical view compilers have for "freestanding" mode, and I think the implementation should be more along the lines of a "micro-libc", than something built into clang. Especially considering the potential future additions e.g. errno.h. If we look at this as a specification for what to provide in a "micro-libc", having such global state is not a major issue, but if we look at this as a "compiler builtin" sort of thing (ala traditional freestanding), then it's quite a problem.

So, I think the correct solution here is to just document what parts of a C2x-conforming "freestanding" Clang provides itself, and what remains for an external "mini-libc" implementation to provide.

It probably makes sense for one such external implementation to be provided by llvm-libc in the future -- I suspect it should have a separate "freestanding" target mode, which would omit all the runtime features like memory allocation and threads, and provide just the pure library functionality. But I'd also expect such an llvm-libc freestanding mode would also provide a lot more functionality than just the minimum requirements -- there's a whole lot more "pure library" functions in C than just the ones required in the new "freestanding" standard.

[aaron.ballman]

In D144889#4157257, @jyknight wrote:

In D144889#4156974, @rsmith wrote:

Likely because of GCC's perspective on this, the set of C headers provided by GCC, Clang, ICC, etc. has included the complete list of freestanding headers and more or less no others, with some libc implementations providing the full set and some providing just the non-freestanding ones. If we're moving away from that, we'll presumably need a new agreement between compiler folks and libc folks about which headers are provided by whom (and I expect it'll be "compilers provide what the C standard said before this change to freestanding and we pretend the change never happened").

Yeah...this seems like a pretty big divergence from the historical view compilers have for "freestanding" mode, and I think the implementation should be more along the lines of a "micro-libc", than something built into clang. Especially considering the potential future additions e.g. errno.h. If we look at this as a specification for what to provide in a "micro-libc", having such global state is not a major issue, but if we look at this as a "compiler builtin" sort of thing (ala traditional freestanding), then it's quite a problem.

On the one hand, I think many users will want a libc that targets their particular freestanding environment so that they get the best performance characteristics (and other considerations) for their target. This suggests the micro-libc approach. On the other hand, I think a not-insignificant number of users are interested in freestanding environments for one-off/fun/experimental projects where ease of access is more important than performance characteristics -- think: users who are playing around with an arduino, etc. This suggests a complete freestanding implementation may be preferable. It's somewhat hard to swallow to ask someone to go find a freestanding C library for a fun-time hardware project that might not have fantastic documentation just so the user can use strlen -- I suspect a nontrivial number of those folks are going to write their own strlen function and be done with it rather than try to solve C and C++'s terrible lack of package management. But it's also an awful lot of effort to write a custom implementation of strtok on the off chance a fun-time hardware project might want to use it.

tl;dr: I don't know there's a clear "winner" approach, but I want to make sure we keep in mind the user experience for the full breadth of users we support.

So, I think the correct solution here is to just document what parts of a C2x-conforming "freestanding" Clang provides itself, and what remains for an external "mini-libc" implementation to provide.

I think that makes sense. From what I'm reading, it sounds like that documentation is effectively pointing out that -ffreestanding mode in Clang will provide headers containing type definitions and macros for target-specific information that only the compiler knows about, expects the user to provide an implementation of memcpy, memmove, and memset (others?), but otherwise leaves all freestanding C standard library functions up to a user-provided library. Is that about what we'd want to document or do you expect more? (I can try to put together some docs we can iterate on.)

It probably makes sense for one such external implementation to be provided by llvm-libc in the future -- I suspect it should have a separate "freestanding" target mode, which would omit all the runtime features like memory allocation and threads, and provide just the pure library functionality. But I'd also expect such an llvm-libc freestanding mode would also provide a lot more functionality than just the minimum requirements -- there's a whole lot more "pure library" functions in C than just the ones required in the new "freestanding" standard.

+1

[bcraig]

Let's talk about these use cases.

On the one hand, I think many users will want a libc that targets their particular freestanding environment so that they get the best performance characteristics (and other considerations) for their target.

I think this fits kernel driver environments, GPUs, and other environments where the vendor is heavily involved in compiler development. The vendor is likely to provide extensions to their freestanding implementation as well (like math.h functions for GPUs).

On the other hand, I think a not-insignificant number of users are interested in freestanding environments for one-off/fun/experimental projects where ease of access is more important than performance characteristics -- think: users who are playing around with an arduino, etc.

This is also an important use case. I don't think it rules out a "stock" freestanding implementation though. A toolchain could reasonably ship one freestanding static library for each ISA-subset / target-triple they want to support, and it could work regardless of the target operating system. memcpy has the same assembly whether it's on OpenRTOS or threadx or MyHomeGrownOS, so long as all are on the same processor with the same calling conventions. A toolchain could also try the header-only approach and lean on the optimizer to turn strcpy into reasonable assembly.

I will definitely agree on the big point with this use case though. I don't want to force every OS vendor to also need to be a compiler / libc vendor, so long as they are willing to settle for the freestanding subset of the language. I also don't want to force them to rewrite strcpy and friends.

[jyknight]

On the other hand, I think a not-insignificant number of users are interested in freestanding environments for one-off/fun/experimental projects where ease of access is more important than performance characteristics -- think: users who are playing around with an arduino, etc.

I agree. But, I see no reason that building the micro-libc for a given target should be any more onerous than building the compiler-rt builtins for said target -- which you already need to do! And it doesn't actually help to make micro-libc _less_ onerous to build than compiler-rt builtins, since you also need that...

Of course, building compiler-rt builtins actually IS rather onerous for users at the moment. This is quite unfortunate, and we should definitely improve the experience of that. And then do the same thing for any micro-libc target. (I think it might go a long way to do something along the lines of distributing target-independent sources and a _trivial_ standalone builtins build script with Clang, such that a user could on-demand build a libclang_builtins.a for any target configuration they wish to use. But that's really a topic for a different thread.)

[aaron.ballman]

In D144889#4158935, @jyknight wrote:

On the other hand, I think a not-insignificant number of users are interested in freestanding environments for one-off/fun/experimental projects where ease of access is more important than performance characteristics -- think: users who are playing around with an arduino, etc.

I agree. But, I see no reason that building the micro-libc for a given target should be any more onerous than building the compiler-rt builtins for said target -- which you already need to do! And it doesn't actually help to make micro-libc _less_ onerous to build than compiler-rt builtins, since you also need that...

In my ideal world (which might not be practical!), the user doesn't build compiler-rt at all (they don't even need to know it's a thing) -- they use whatever means they usually do to get clang installed on their system and that's sufficient for them to work on their project. So, to me, asking the user to build a micro-libc or compiler-rt is somewhat onerous in and of itself.

clang/docs/ReleaseNotes.rst

 
 - Removed the ``ATOMIC_VAR_INIT`` macro in C2x and later standards modes, which
   implements `WG14 N2886 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2886.htm>`_
 
 - Implemented `WG14 N2934 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2934.pdf>`_
   which introduces the ``bool``, ``static_assert``, ``alignas``, ``alignof``,
   and ``thread_local`` keywords in C2x.
 
+- Added ``<string.h>`` to the list of headers supported by freestanding
+  compilations. This partially implements
+  `WG14 N2524 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2524.htm>`_,
+  but does not yet support ``memccpy``, ``memset_explicit``, or ``strtok`` yet.
+  NB, Clang does not yet support WG14 N3020 yet either, which impacts the
+  signatures of the functions in ``<string.h>``.
+
 Non-comprehensive list of changes in this release
 -------------------------------------------------
 - Clang now saves the address of ABI-indirect function parameters on the stack,
   improving the debug information available in programs compiled without
   optimizations.
 - Clang now supports ``__builtin_nondeterministic_value`` that returns a
   nondeterministic value of the same type as the provided argument.
 

clang/lib/Headers/CMakeLists.txt

set(core_files
   stdalign.h
   stdarg.h
   stdatomic.h
   stdbool.h
   stddef.h
   __stddef_max_align_t.h
   stdint.h
   stdnoreturn.h
+  string.h
   tgmath.h
   unwind.h
   varargs.h
   )
 
 set(arm_common_files
   # Headers shared by Arm and AArch64
   arm_acle.h

clang/lib/Headers/string.h

+/*===---- string.h - Standard header for freestanding string facilities----===*\
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+\*===----------------------------------------------------------------------===*/
+
+#ifndef __CLANG_STRING_H
+/* If we're hosted or in C17 or earlier, use the system string.h if it's
+ * available.
+ * FIXME: This is using the placeholder dates Clang produces for these macros
+ * in C2x mode; switch to the correct values once they've been published.
+ */
+#if (__STDC_HOSTED__ ||                                                        \
+      (defined(__STDC_VERSION__) && __STDC_VERSION__ < 202000L)) &&            \
+    __has_include_next(<string.h>)
+#include_next <string.h>
+#else
+
+/* C2x 7.26.1p2 */
+/* FIXME: Once we support memccpy, strtok, and memset_explicit, set this value
+ * to 202311L as required by the standard. For now, we use an older value.
+ */
+#define __STDC_VERSION_STRING_H__ 202300L
+
+/* C2x Clause 4p6: ... the features specified in the header <string.h> are
+ * used, except the following functions:
+ * strdup, strndup, strcoll, strxfrm, strerror; and/or, ...
+ */
+
+/* Copying Functions
+ *
+ * void *memcpy(void * restrict s1, const void * restrict s2, size_t n);
+ * FIXME: void *memccpy(void * restrict s1, const void * restrict s2, int c,
+                 size_t n);
+ * void *memmove(void *s1, const void *s2, size_t n);
+ * char *strcpy(char * restrict s1, const char * restrict s2);
+ * char *strncpy(const * restrict s1, const char * restruct s2, size_t n);
+ */
+#define memcpy(__s1, __s2, __n) __builtin_memcpy(__s1, __s2, __n)
+#define memmove(__s1, __s2, __n) __builtin_memmove(__s1, __s2, __n)
+#define strcpy(__s1, __s2) __builtin_strcpy(__s1, __s2)
+#define strncpy(__s1, __s2, __n) __builtin_strncpy(__s1, __s2, __n)
+
+/* Concatenation Functions
+ *
+ * char *strcat(char * restrict s1, const char * restrict s2);
+ * char *strncat(char * restrict s1, const char * restrict s2, size_t n);
+ */
+#define strcat(__s1, __s2) __builtin_strcat(__s1, __s2)
+#define strncat(__s1, __s2, __n) __builtin_strncat(__s1, __s2, __n)
+
+/* Comparison Functions
+ *
+ * int memcmp(const void *s1, const void *s2, size_t n);
+ * int strcmp(const char *s1, const char *s2);
+ * int strncmp(const char *s1, const char *s2, size_t n);
+ */
+#define memcmp(__s1, __s2, __n) __builtin_memcmp(__s1, __s2, __n)
+#define strcmp(__s1, __s2) __builtin_strcmp(__s1, __s2)
+#define strncmp(__s1, __s2, __n) __builtin_strncmp(__s1, __s2, __n)
+
+/* Search Functions
+ *
+ * QVoid *memchr(QVoid *s, int c, size_t n);
+ * QChar *strchr(QChar *s, int c);
+ * size_t strcspn(const char *s1, const char *s2);
+ * QChar *strpbrk(QChar *s1, const char *s2);
+ * QChar *strrchr(QChar *s1, int c);
+ * size_t strspn(const char *s1, const char *s2);
+ * QChar *strstr(QChar *s1, const char *s2);
+ * FIXME: char *strtok(char * restrict s1, const char * restrict s2);
+ */
+#define memchr(__s, __c, __n) __builtin_memchr(__s, __c, __n)
+#define strchr(__s, __c) __builtin_strchr(__s, __c)
+#define strcspn(__s1, __s2) __builtin_strcspn(__s1, __s2)
+#define strpbrk(__s1, __s2) __builtin_strpbrk(__s1, __s2)
+#define strrchr(__s1, __c) __builtin_strrchr(__s1, __c)
+#define strspn(__s1, __s2) __builtin_strspn(__s1, __s2)
+#define strstr(__s1, __s2) __builtin_strstr(__s1, __s2)
+
+/* Miscellaneous Functions
+ *
+ * void *memset(void *s, int c, size_t n);
+ * FIXME: void *memset_explicit(void *s, int c, size_t n);
+ * size_t strlen(const char *s);
+ */
+#define memset(__s, __c, __n) __builtin_memset(__s, __c, __n)
+#define strlen(__s) __builtin_strlen(__s)
+
+#endif /* __STDC_HOSTED__ || __STDC_VERSION__ < C2x */
+#endif /* __CLANG_STRING_H */
+

clang/lib/Lex/ModuleMap.cpp

return llvm::StringSwitch<bool>(FileName)
            .Case("iso646.h", true)
            .Case("limits.h", true)
            .Case("stdalign.h", true)
            .Case("stdarg.h", true)
            .Case("stdatomic.h", true)
            .Case("stdbool.h", true)
            .Case("stddef.h", true)
            .Case("stdint.h", true)
+           .Case("string.h", true)
            .Case("tgmath.h", true)
            .Case("unwind.h", true)
            .Default(false);
 }
 
 bool ModuleMap::isBuiltinHeader(const FileEntry *File) {
   return File->getDir() == BuiltinIncludeDir &&
          ModuleMap::isBuiltinHeader(llvm::sys::path::filename(File->getName()));

clang/test/C/C2x/n2524.c

+// RUN: %clang_cc1 -std=c2x %s -ffreestanding -verify
+// RUN: %clang_cc1 -std=c2x %s -ffreestanding -DCODEGEN -emit-llvm -o - | FileCheck %s
+
+/* WG14 N2524: partial
+ * String functions for freestanding implementations
+ *
+ * We have partial support, but are still missing builtin implementations for:
+ *   memccpy
+ *   memset_explicit
+ *   strtok
+ * before we can claim full support.
+ */
+
+#include <string.h>
+
+/* Ensure that the version macro is defined to the value we expect. */
+#ifndef __STDC_VERSION_STRING_H__
+#error "expected __STDC_VERSION_STRING_H__ to be defined"
+#elif __STDC_VERSION_STRING_H__ != 202300L /* FIXME: This should change to 202311L when ready */
+#error "expected __STDC_VERSION_STRING_H__ to be 202311L"
+#endif
+
+/* Ensure that we emit the expected calls to a builtin function when using the
+ * various freestanding interfaces.
+ */
+void test(char *buffer1, char *buffer2, typeof(sizeof(0)) count, int n) {
+  memcpy(buffer1, buffer2, count);
+  // CHECK: call void @llvm.memcpy.p0.p0.
+  // FIXME memccpy(buffer1, buffer2, count, n);
+  memmove(buffer1, buffer2, count);
+  // CHECK: call void @llvm.memmove.p0.p0.
+  strcpy(buffer1, buffer2);
+  // CHECK: call ptr @strcpy
+  strncpy(buffer1, buffer2, count);
+  // CHECK: call ptr @strncpy
+
+  strcat(buffer1, buffer2);
+  // CHECK: call ptr @strcat
+  strncat(buffer1, buffer2, count);
+  // CHECK: call ptr @strncat
+
+  memcmp(buffer1, buffer2, count);
+  // CHECK: call i32 @memcmp
+  strcmp(buffer1, buffer2);
+  // CHECK: call i32 @strcmp
+  strncmp(buffer1, buffer2, count);
+  // CHECK: call i32 @strncmp
+
+  memchr(buffer1, n, count);
+  // CHECK: call ptr @memchr
+  strchr(buffer1, n);
+  // CHECK: call ptr @strchr
+  strcspn(buffer1, buffer2);
+  // CHECK: call i{{32|64}} @strcspn
+  strpbrk(buffer1, buffer2);
+  // CHECK: call ptr @strpbrk
+  strrchr(buffer1, n);
+  // CHECK: call ptr @strrchr
+  strspn(buffer1, buffer2);
+  // CHECK: call i{{32|64}} @strspn
+  strstr(buffer1, buffer2);
+  // CHECK: call ptr @strstr
+  // FIXME: strtok(buffer1, buffer2);
+
+  memset(buffer1, n, count);
+  // CHECK: call void @llvm.memset.p0
+  // FIXME: memset_explicit(buffer1, n, count);
+  strlen(buffer1);
+  // CHECK: call i{{32|64}} @strlen
+}
+
+/* Some functions take and return a QVoid * or QChar * because the interface
+ * is expected to work with both a pointer to a const-qualified type as well as
+ * a pointer to a non-const-qualified type. Ensure we get the correct type
+ * interfaces we expect.
+ *
+ * This is a feature of WG14 N3020 rather than N2524, but because Clang doesn't
+ * vend libc directly, the only way to test this is with the freestanding
+ * implementation we support.
+ *
+ * FIXME: this support needs to be implemented still. Once the support is added
+ * and these assertions pass, combine the RUN lines and drop -DCODEGEN.
+ */
+#ifndef CODEGEN
+#define TEST(T, Expected) _Generic(T, Expected : 1, default : 0)
+_Static_assert(TEST(memchr((void *)0, 0, 0), void *), "");
+_Static_assert(TEST(memchr((const void *)0, 0, 0), const void *), ""); // expected-error {{static assertion failed}}
+
+_Static_assert(TEST(strchr((char *)0, 0), char *), "");
+_Static_assert(TEST(strchr((const char *)0, 0), const char *), ""); // expected-error {{static assertion failed}}
+
+_Static_assert(TEST(strpbrk((char *)0, 0), char *), "");
+_Static_assert(TEST(strpbrk((const char *)0, 0), const char *), ""); // expected-error {{static assertion failed}}
+
+_Static_assert(TEST(strrchr((char *)0, 0), char *), "");
+_Static_assert(TEST(strrchr((const char *)0, 0), const char *), ""); // expected-error {{static assertion failed}}
+
+_Static_assert(TEST(strstr((char *)0, 0), char *), "");
+_Static_assert(TEST(strstr((const char *)0, 0), const char *), ""); // expected-error {{static assertion failed}}
+#endif // CODEGEN

clang/www/c_status.html

<tr>
       <td>Unclear type relationship between a format specifier and its argument</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2562.pdf">N2562</a></td>
       <td class="unreleased" align="center">Clang 16</td>
     </tr>
     <!-- Apr 2021 Papers -->
     <tr>
       <td>String functions for freestanding implementations</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2524.htm">N2524</a></td>
-      <td class="none" align="center">No</td>
+      <td class="partial" align="center">
+        <details><summary>Partial</summary>
+          Clang implements all of the freestanding functions from string.h
+          except <code>memset_explicit</code>, <code>strtok</code>, and
+          <code>memccpy</code>. Additionally, Clang is missing support for
+          WG14 N3020 that impacts some of the function return types based on
+          the signature used.
+        </details>
+      </td>
     </tr>
     <tr>
       <td>Digit separators</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2626.pdf">N2626</a></td>
       <td class="full" align="center">Clang 13</td>
     </tr>
     <tr>
       <td>Missing +(x) in table</td>
<tr>
       <td class="unknown" align="center">Unknown</td>
     </tr>
     <tr>
       <td>Relax requirements for va_start</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2975.pdf">N2975</a></td>
       <td class="unreleased" align="center">Clang 16</td>
     </tr>
     <tr>
+      <td>Qualifier-preserving standard library functions, v4</td>
+      <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3020.pdf">N3020</a></td>
+      <td class="none" align="center">No</td>
+    </tr>
+    <tr>
       <td>Enhanced enumerations</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3030.htm">N3030</a></td>
       <td class="unknown" align="center">Unknown</td>
     </tr>
     <tr>
       <td>Freestanding C and IEC 60559 conformance scope reduction</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2951.htm">N2951</a></td>
       <td class="unknown" align="center">Unknown</td>