Am 06.05.2020 um 22:36 schrieb Philipp Klaus Krause:> Yes, but one benefit of standardization is providing a baseline of > functionality that C programmers can target.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.
Making more of the C standard library mandatory for freestanding implementations
Started by ●May 6, 2020
Reply by ●May 6, 20202020-05-06
Reply by ●May 6, 20202020-05-06
On 2020-05-06, Hans-Bernhard Bröker <HBBroeker@t-online.de> wrote:> Am 06.05.2020 um 22:36 schrieb Philipp Klaus Krause: > >> Yes, but one benefit of standardization is providing a baseline of >> functionality that C programmers can target. > > [...] > > 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.The arguments about "printf" alone would take decades and cost thousands of lives. :) -- Grant
Reply by ●May 6, 20202020-05-06
On 5/6/20 4:22 PM, Keith Thompson wrote:> 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.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).> > 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 ...". >Yes, making the parts of the option headers supported be 'Implementation Defined' might make sense.
Reply by ●May 7, 20202020-05-07
On Wed, 6 May 2020 22:34:16 +0200, Philipp Klaus Krause <pkk@spth.de> wrote:>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. [�] > >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.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 by ●May 7, 20202020-05-07
Am 06.05.20 um 23:25 schrieb Hans-Bernhard Bröker:> Am 06.05.2020 um 22:36 schrieb Philipp Klaus Krause: > >> Yes, but one benefit of standardization is providing a baseline of >> functionality that C programmers can target. > > 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. >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 by ●May 7, 20202020-05-07
Am 06.05.20 um 23:34 schrieb Grant Edwards:> On 2020-05-06, Hans-Bernhard Bröker <HBBroeker@t-online.de> wrote: > >> Am 06.05.2020 um 22:36 schrieb Philipp Klaus Krause: >> >>> Yes, but one benefit of standardization is providing a baseline of >>> functionality that C programmers can target. >> >> [...] >> >> 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. > > The arguments about "printf" alone would take decades and cost > thousands of lives. :)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 by ●May 7, 20202020-05-07
On 07/05/2020 04:29, Richard Damon wrote:> On 5/6/20 4:22 PM, Keith Thompson wrote:<snip>>> 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 ...". >> > > Yes, making the parts of the option headers supported be 'Implementation > Defined' might make sense. >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 by ●May 7, 20202020-05-07
On 7.5.20 11:17, Philipp Klaus Krause wrote:> Am 06.05.20 um 23:34 schrieb Grant Edwards: >> On 2020-05-06, Hans-Bernhard Bröker <HBBroeker@t-online.de> wrote: >> >>> Am 06.05.2020 um 22:36 schrieb Philipp Klaus Krause: >>> >>>> Yes, but one benefit of standardization is providing a baseline of >>>> functionality that C programmers can target. >>> >>> [...] >>> >>> 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. >> >> The arguments about "printf" alone would take decades and cost >> thousands of lives. :) > > 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.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 by ●May 7, 20202020-05-07
On 6.5.20 23:34, Philipp Klaus Krause wrote:> 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. […] > > 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 >The shared/dynamic libraries contain all the functions with their entry points listed separately. -- -TV
Reply by ●May 7, 20202020-05-07
On 2020-05-07, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:> The shared/dynamic libraries contain all the functions with > their entry points listed separately.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
