Forums

Making more of the C standard library mandatory for freestanding implementations

Started by Philipp Klaus Krause May 6, 2020
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