Re: Internal organization of "the implementation" (was: [PATCH] Add example to rand.3)

[Joseph Myers <joseph@codesourcery.com>]

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@codesourcery.com