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:

formatting link

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

Reply to
Philipp Klaus Krause
Loading thread data ...

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

Memory size.

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

--
Grant
Reply to
Grant Edwards

Am 06.05.20 um 18:47 schrieb Grant Edwards:

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

Reply to
Philipp Klaus Krause

Would that be required by the spec?

--
Grant
Reply to
Grant Edwards

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?

Reply to
James Kuyper

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.

Reply to
Richard Damon

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 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 
 Click to see the full signature
Reply to
Keith Thompson

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

Reply to
Philipp Klaus Krause

Am 06.05.20 um 22:08 schrieb Richard Damon:

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

Reply to
Philipp Klaus Krause

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
Reply to
Grant Edwards

Am 06.05.2020 um 22:36 schrieb Philipp Klaus Krause:

And a baseline belongs exactly there: at the base of the building, i.e. all the way down. At the bottom. And there can be only _one_ baseline.

We have names for the two relevant feature completeness levels: the baseline is "freestanding", the top edge is "hosted", and IMHO that's completely correct like that.

I very much doubt there's a need for more named levels. And even if there were such a need, there's simply no way people would ever agree on where, exactly, those levels should be. So in the end the number of such level can be either be either 1, 2 or infinite.

Reply to
Hans-Bernhard Bröker

The arguments about "printf" alone would take decades and cost thousands of lives. :)

--
Grant
Reply to
Grant Edwards

In fact, it is quite common to implement parts intentionally 'incorrectly', I have had many with a printf that totally omitted float point formats because that support is EXPENSIVE (especially if that is the only floating point code in the program).

Yes, making the parts of the option headers supported be 'Implementation Defined' might make sense.

Reply to
Richard Damon

The standard practice for at least half a century has been to put only a single library function into a source file and compile each module separately.

In the most primitive form just add the names of the required library object files at the end of the linker command line.

A more elaborate library systems put these object files into a single library file, builds a symbol table for global functions defined in each library module. When the linker has linked the user program and there are still undefined external references, scan the library symbol table to find which module defines the required global symbol. Then seek() to the start of the module and read it in. If there are new undefined symbols, repeat the library symbol table scan.

Reply to
upsidedown

Yes. And I am arguing that this baseline should include most of string.h. The baseline should omit everything that is hard to implement on some hardware (e.g. dynamic memory, I/O, certain minimum values for implementation limits). But it should include stuff such as memcpy(), that can be implemented on any hardware.

Reply to
Philipp Klaus Krause

Am 06.05.20 um 23:34 schrieb Grant Edwards:

I guess so. And I'm not arguing that printf() should be mandatory for freestanding implementations. But I see quite some difference between printf and memcpy.

Reply to
Philipp Klaus Krause

Indeed - "implementation defined" means it has to be properly documented.

Perhaps there could be wording to say that the optional headers (and their associated functions) can be omitted for freestanding implementations - but for each header that is provided, it must either be fully conforming or document any limitations or changes.

Other than that, I don't see any need to make other parts of the library non-optional. In practice, toolchains invariably implement all functions that make sense on the target - they have abs(), and memcpy(), and the like. But they might have non-conforming printf (as mentioned already), and typically omit file-related functions and wide character functions on smaller systems.

I can't see an issue with portability, as you simply don't expect to be able to use code with file handling on a device with no file system, or wide characters on a system with no display.

Reply to
David Brown

printf() is a can of worms in a bare-metal environment. If it is implemented in the standard way, it needs the whole kit and caboodle of standard I/O, including dynamic memory allocation. It is luxury that does not fit into a small embedded device.

--

-TV
Reply to
Tauno Voipio

The shared/dynamic libraries contain all the functions with their entry points listed separately.

--

-TV
Reply to
Tauno Voipio

I've never seen a freestanding target that had shared/dynamic libraries. All of the freestanding targets I've ever worked with ran as a single statically linked binary executable.

--
Grant
Reply to
Grant Edwards

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.