On Fri, 30 Dec 2022, Alejandro Colomar via Libc-alpha wrote: > Why is this duplication of responsibility for libc functions? Why isn't there There isn't duplication. Each function is the responsibility of exactly one of the compiler and the libc; GCC's documentation, once updated for C2x, will reflect which parts it expects to provide and which it expects a corresponding libc to provide. > 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? The design follows from the traditional structure of libc on Unix systems (containing both functions closely related to the OS and functions that only depend on the CPU architecture and not the OS) and GCC's early role as an alternative to the system compiler there. It's possible to structure libraries in lots of different ways (I don't know if BSD systems actually share parts of libc with the kernel, but they certainly tend to have closer integration of code across the whole system, for example). Non-C-family languages are probably a better place for exploring the design space of different divisions among compilers and libraries, than C libraries that are expected to fit with existing tooling, build systems and operating systems (and certainly the extreme case of a very large number of separately maintained tiny libraries in some such language environments shows up its own problems with dependency management). In practice, while there's sometimes sharing at the level of a third-party source code repository providing code that can be used in multiple places (see Arm's optimized routines, for example), including code in shared libraries and using features such as IFUNC, along with e.g. some objects having multiple entry points and other libc-internal symbol handling requiring close coordination among the build of all linked objects, makes it hard to share at the object code level. And we've tended lately to move *away* from separate small shared libraries - rather, integrating formerly separate libraries such as libpthread into the single shared libc. -- Joseph S. Myers joseph@xxxxxxxxxxxxxxxx
