Making more of the C standard library mandatory for freestanding implementations

In C, most of the standard library is mandatory for hosted
implementations only, not for freestadning implementations.
Still, I see many functions, such as memcpy() and abs() often used in
programs for embedded systems, and see no obstacles to implementing them
even on small systems.

Should more of the standard library become mandatory for freestanding
implementations?

For string.h, I have written a first draft of a proposal:

http://www.colecovision.eu/stuff/proposal-freestanding-string.html

What do you think of it?

Do you see any reason those could not be provided on some C implementation?

Which further functions would you like to become mandatory for
freestanding C implementations?

Philipp

On 2020-05-06, Philipp Klaus Krause <pkk@spth.de> wrote:

> In C, most of the standard library is mandatory for hosted
> implementations only, not for freestadning implementations.  Still,
> I see many functions, such as memcpy() and abs() often used in
> programs for embedded systems, and see no obstacles to implementing
> them even on small systems.
>
> Should more of the standard library become mandatory for
> freestanding implementations?

No.  Just No.  For use on small embedded systems, there must be a
"bare metal" option that requires no standard library functions.

> For string.h, I have written a first draft of a proposal:
>
> http://www.colecovision.eu/stuff/proposal-freestanding-string.html
>
> What do you think of it?
>
> Do you see any reason those could not be provided on some C
> implementation?

Memory size.

> Which further functions would you like to become mandatory for
> freestanding C implementations?

NONE.  Freestanding, should remain freestanding.  If you want to
define some "semi-hosted" spec, that's fine.  Leave freestanding
alone.

--
Grant

Am 06.05.20 um 18:47 schrieb Grant Edwards:
>>
>> Do you see any reason those could not be provided on some C
>> implementation?
> 
> Memory size.

Could you elaborate?

I do not see a problem there: If the programmer doesn't use e.g.
memcpy(), no memcpy() will be linked in, so memory size would not be
affected. And if the programmer needs the functionality of memcpy(), I
don't see why using it would be worse than the programmer rollinghteir
own version.

Philipp

On 2020-05-06, Philipp Klaus Krause <pkk@spth.de> wrote:
> Am 06.05.20 um 18:47 schrieb Grant Edwards:
>>>
>>> Do you see any reason those could not be provided on some C
>>> implementation?
>> 
>> Memory size.
>
> Could you elaborate?
>
> I do not see a problem there: If the programmer doesn't use e.g.
> memcpy(), no memcpy() will be linked in, so memory size would not be
> affected.

Would that be required by the spec?

--
Grant

On 5/6/20 2:10 PM, Grant Edwards wrote:
> On 2020-05-06, Philipp Klaus Krause <pkk@spth.de> wrote:
>> Am 06.05.20 um 18:47 schrieb Grant Edwards:
>>>>
>>>> Do you see any reason those could not be provided on some C
>>>> implementation?
>>>
>>> Memory size.
>>
>> Could you elaborate?
>>
>> I do not see a problem there: If the programmer doesn't use e.g.
>> memcpy(), no memcpy() will be linked in, so memory size would not be
>> affected.
> 
> Would that be required by the spec?

No, but it might be required by the marketplace. If you had a choice of
two compilers, one of which always links in standard library routines
even if they're unused, and the other of which only links them in if
they are used, which one would you select, particularly if targeting a
platform with only limited memory? Do you think there's any significant
number of people who would choose differently?

On 5/6/20 3:10 PM, James Kuyper wrote:
> On 5/6/20 2:10 PM, Grant Edwards wrote:
>> On 2020-05-06, Philipp Klaus Krause <pkk@spth.de> wrote:
>>> Am 06.05.20 um 18:47 schrieb Grant Edwards:
>>>>>
>>>>> Do you see any reason those could not be provided on some C
>>>>> implementation?
>>>>
>>>> Memory size.
>>>
>>> Could you elaborate?
>>>
>>> I do not see a problem there: If the programmer doesn't use e.g.
>>> memcpy(), no memcpy() will be linked in, so memory size would not be
>>> affected.
>>
>> Would that be required by the spec?
> 
> No, but it might be required by the marketplace. If you had a choice of
> two compilers, one of which always links in standard library routines
> even if they're unused, and the other of which only links them in if
> they are used, which one would you select, particularly if targeting a
> platform with only limited memory? Do you think there's any significant
> number of people who would choose differently?
> 

By that same logic, people will chose the implementation that implement
more of the optional headers (or at least the ones they want) over those
that don't. There is nothing in the Standard to say that they can't
implement the part that aren't required.

Richard Damon <Richard@Damon-Family.org> writes:
> On 5/6/20 3:10 PM, James Kuyper wrote:
>> On 5/6/20 2:10 PM, Grant Edwards wrote:
>>> On 2020-05-06, Philipp Klaus Krause <pkk@spth.de> wrote:
>>>> Am 06.05.20 um 18:47 schrieb Grant Edwards:
>>>>>>
>>>>>> Do you see any reason those could not be provided on some C
>>>>>> implementation?
>>>>>
>>>>> Memory size.
>>>>
>>>> Could you elaborate?
>>>>
>>>> I do not see a problem there: If the programmer doesn't use e.g.
>>>> memcpy(), no memcpy() will be linked in, so memory size would not be
>>>> affected.
>>>
>>> Would that be required by the spec?
>> 
>> No, but it might be required by the marketplace. If you had a choice of
>> two compilers, one of which always links in standard library routines
>> even if they're unused, and the other of which only links them in if
>> they are used, which one would you select, particularly if targeting a
>> platform with only limited memory? Do you think there's any significant
>> number of people who would choose differently?
>
> By that same logic, people will chose the implementation that implement
> more of the optional headers (or at least the ones they want) over those
> that don't. There is nothing in the Standard to say that they can't
> implement the part that aren't required.

True.  On the other hand, there's nothing in the Standard to say that a
freestanding implementation that implements part of the hosted standard
library has to do it correctly.

You probably wouldn't want to require that.  For example, an
implementation might reasonably provide printf but not fprintf, or
provide printf but without floating-point support.  It would be
difficult to define the requirements for partial support.

It's probably good enough that a freestanding implementation's
documentation can say something like "We support <stdio.h> as specified
by C11 with the following exceptions ...".

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Am 06.05.20 um 21:10 schrieb James Kuyper:
> On 5/6/20 2:10 PM, Grant Edwards wrote:
>> On 2020-05-06, Philipp Klaus Krause <pkk@spth.de> wrote:
>>> Am 06.05.20 um 18:47 schrieb Grant Edwards:
>>>>>
>>>>> Do you see any reason those could not be provided on some C
>>>>> implementation?
>>>>
>>>> Memory size.
>>>
>>> Could you elaborate?
>>>
>>> I do not see a problem there: If the programmer doesn't use e.g.
>>> memcpy(), no memcpy() will be linked in, so memory size would not be
>>> affected.
>>
>> Would that be required by the spec?
> 
> No, but it might be required by the marketplace. [&hellip;]

While compilers exist, that cannot remove unused functions from
non-library user code (though such removal is now a common feature), I
do not know of any compilers that would link in the whole standard
library. All implementations known to me will only link in the used
parts of the standard library.

Philipp

Am 06.05.20 um 22:08 schrieb Richard Damon:
>>
>> No, but it might be required by the marketplace. If you had a choice of
>> two compilers, one of which always links in standard library routines
>> even if they're unused, and the other of which only links them in if
>> they are used, which one would you select, particularly if targeting a
>> platform with only limited memory? Do you think there's any significant
>> number of people who would choose differently?
>>
> 
> By that same logic, people will chose the implementation that implement
> more of the optional headers (or at least the ones they want) over those
> that don't. There is nothing in the Standard to say that they can't
> implement the part that aren't required.
> 

Yes, but one benefit of standardization is providing a baseline of
functionality that C programmers can target.
This is somewhat different from optimization (such as not linkingunused
parts of the stadnard library).

On 2020-05-06, Philipp Klaus Krause <pkk@spth.de> wrote:

> Yes, but one benefit of standardization is providing a baseline of
> functionality that C programmers can target.

IMO, talking about a standardized baseline of library functionality
for bare-metal freestanding targets doesn't make much sense.  In my
experience, freestanding projects tend to be very idiosyncratic.

--
Grant