Re: [PATCH] Add example to rand.3

[Joseph Myers <joseph@codesourcery.com>]

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

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

-- 
Joseph S. Myers
joseph@codesourcery.com