Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.std.c
Subject: Re: Making more of the C standard library mandatory for freestanding implementations
Date: Fri, 08 May 2020 08:38:14 -0700
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <86blmyzbbt.fsf@linuxsc.com>
References: <r8uo2j$4l2$1@solani.org> <r8upn1$89t$1@reader2.panix.com> <r8urd0$7el$1@solani.org> <r8uuj1$3j8$1@reader2.panix.com> <r8v23k$ak4$1@dont-email.me> <TOEsG.61838$iB5.60372@fx06.iad> <r8v75a$h2l$2@solani.org> <3e5a2404-f2a9-3503-31f6-1c0040d34945@t-online.de> <r90g5b$d34$1@solani.org> <hhj6fkFo22dU1@mid.dfncis.de> <r91of6$ds7$1@solani.org> <878si3bjwe.fsf@nightsong.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="b5e8c1925c1f5a62ad5a60468d6da6c6"; logging-data="20480"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19/jwcETkpKyIKQVmo8fHT7O5rkqXsRbFc="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:jQqGySwAEKVRWtg9IZtFEWFdxdQ= sha1:j/npUmYkQN+Z2yPSg3/L6GU6QAc=
Xref: csiph.com comp.std.c:6108

Paul Rubin <no.email@nospam.invalid> writes:

> Philipp Klaus Krause <pkk@spth.de> writes:
>
>> For many embedded users, memcpy() might be more useful and necessary
>> than long long or float.  Also, memcpy() is easier to implement than
>> support for long long or float.  Still the latter are currently mandatory
>> for freestanding implementations, while the former is not.
>
> Forth has a core wordset (basically a library) and a bunch of separate
> optional wordsets, each of which is standardized.  Floating point
> arithmetic is an optional wordset so it's fine if your implementation
> doesn't have it.  But if you do choose to supply floating point
> features, the standard says what those features should do, so you don't
> have to make it up as you go along.
>
> Maybe C could use a similar approach.

What I like about your idea is the notion that an interface is
standardized, and an implementation gets a binary choice,
either to provide it as specified, or just not to provide it.

To make that idea work for case under discussion here (ie, for
string functions), I think that needs to be augmented in two
ways.  One, it needs to be more fine grained than just all of
<string.h>.  Two, it needs to include a way for a program source
to inquire about whether any particular function has been
provided -- probably done using preprocessor symbols -- so that
the program can adapt to different environments, and do that
automatically, without needing to have a separate configuration
step.

For example, under this scheme, we might do this:

    // File "fs_string.h"    

    #include <string-optional.h>   // string.h optional subset

    #if ! _Provides_strlen
    extern size_t strlen( const char * );
    #endif

    ...

    // File "fs_string.c"

    #include "fs_string.h"

    #if ! _Provides_strlen
    size_t
    strlen( const char *s ){
        size_t r = 0;
        while(  *s++  )  r++;
        return  r;
    }

    #endif

Now the rest of the program can simply #include "fs_string.h",
and use strlen() just as it would if strlen() was supplied
by the implementation.