Hi Joseph, On 12/30/22 22:08, Joseph Myers wrote: > On Fri, 30 Dec 2022, Cristian Rodríguez via Libc-alpha wrote: > >> On Fri, Dec 30, 2022 at 3:15 PM Joseph Myers wrote: >> >>> I expect to implement these functions in due course for glibc (not GCC, >>> since these are library functions, with the usual requirements for >>> definitions with external linkage, though most would also have inline >>> header implementations based on existing longstanding built-in functions). >> >> Unless I am seriously missing something, the compiler is required to >> provide an implementation >> of them as it is a freestanding header..right ? > > "freestanding" versus "hosted" isn't the right distinction for which > component in a (compiler + library) implementation provides which pieces > any more. The actual distinction is closer to whether a feature involves > library functions (with external linkage): if it does, it belongs in the > library (glibc), whereas if a header doesn't involve such functions, it > belongs in the compiler (GCC), along with the library support (in libgcc) > for language features (i.e. library code that can be needed even by > programs that don't include any standard library header or call any > function from the standard library). My list of things to be done for C2x > in GCC includes updating the GCC documentation (standards.texi) to reflect > this: that is, to say that GCC provides the compiler part of a > freestanding or hosted implementation, and library support for language > features and headers not involving external linkage functions, to be used > together with a corresponding library implementation - not that it's a > freestanding implementation by itself. > > (It wasn't quite right for C11 either; GCC provides and > libatomic, and while there are a few atomic_* functions with external > linkage, the bulk of the operations in are only generic > functions with no defined external-linkage functions underlying them, > while it's been documented for a long time that a corresponding library is > always needed to provided memcpy, memmove and memset as those may be > generated from use of language features without being called explicitly by > the user's code. But C2x makes it a lot more visible that the previously > documented rule of thumb for where a feature goes is no longer > appropriate.) > Why is this duplication of responsibility for libc functions? Why isn't there a smaller say libmem that provides a unique implementation for these memcpy(), memmove(), memset() functions, and both gcc and glibc (and even the kernel could, with static linking) depend on it? Cheers, Alex --