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

[Alejandro Colomar]

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 <joseph@codesourcery.com> 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 <stdatomic.h> and
> libatomic, and while there are a few atomic_* functions with external
> linkage, the bulk of the operations in <stdatomic.h> 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

-- 
<http://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20221230/f94cb111/attachment.sig>