Making more of the C standard library mandatory for freestanding implementations

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: Making more of the C standard library mandatory for freestanding implementations

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Memory size.


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

--
Grant




Re: Making more of the C standard library mandatory for freestanding implementations
Am 06.05.20 um 18:47 schrieb Grant Edwards:
Quoted text here. Click to load it

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

Re: Making more of the C standard library mandatory for freestanding implementations
Quoted text here. Click to load it

Would that be required by the spec?

--
Grant





Re: Making more of the C standard library mandatory for freestanding implementations
On 5/6/20 2:10 PM, Grant Edwards wrote:
Quoted text here. Click to load it

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?


Re: Making more of the C standard library mandatory for freestanding implementations
On 5/6/20 3:10 PM, James Kuyper wrote:
Quoted text here. Click to load it

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.

Re: Making more of the C standard library mandatory for freestanding implementations
Quoted text here. Click to load it

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+ snipped-for-privacy@gmail.com
Working, but not speaking, for Philips Healthcare
We've slightly trimmed the long signature. Click to see the full one.
Re: Making more of the C standard library mandatory for freestanding implementations
On 5/6/20 4:22 PM, Keith Thompson wrote:
Quoted text here. Click to load it

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).
Quoted text here. Click to load it

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

Re: Making more of the C standard library mandatory for freestanding implementations
On 07/05/2020 04:29, Richard Damon wrote:
Quoted text here. Click to load it
<snip>
Quoted text here. Click to load it

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.


Re: Making more of the C standard library mandatory for freestanding implementations
Am 06.05.20 um 22:08 schrieb Richard Damon:
Quoted text here. Click to load it

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

Re: Making more of the C standard library mandatory for freestanding implementations

Quoted text here. Click to load it

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




Re: Making more of the C standard library mandatory for freestanding implementations
Am 06.05.2020 um 22:36 schrieb Philipp Klaus Krause:

Quoted text here. Click to load it

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.

Re: Making more of the C standard library mandatory for freestanding implementations


Quoted text here. Click to load it

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

--
Grant



Re: Making more of the C standard library mandatory for freestanding implementations
Am 06.05.20 um 23:34 schrieb Grant Edwards:

Quoted text here. Click to load it

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.

Re: Making more of the C standard library mandatory for freestanding implementations
On 7.5.20 11:17, Philipp Klaus Krause wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it


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


Re: Making more of the C standard library mandatory for freestanding implementations

Quoted text here. Click to load it

Quoted text here. Click to load it

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.

Re: Making more of the C standard library mandatory for freestanding implementations
Am 07.05.2020 um 10:16 schrieb Philipp Klaus Krause:

Quoted text here. Click to load it

Quoted text here. Click to load it

Why do you say "yes", and then immediately go on by stating the exact  
opposite of what you just agreed to?

Anything that's not absolutely necessary doesn't belong in the baseline.  
  Otherwise it's something else, but not the baseline.

Re: Making more of the C standard library mandatory for freestanding implementations

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it


I meant yes to having only one baseline. However I argue that the line
should not be drawn at an arbitrary point (why draw it between a large
part of the language and the library, rather than somewhere within the
language or the library?). IMO, the line should be drawn based on what
can be easily implemented on virtually all hardware.

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.

Re: Making more of the C standard library mandatory for freestanding implementations
Quoted text here. Click to load it

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.

Re: Making more of the C standard library mandatory for freestanding implementations
Am 06.05.20 um 21:10 schrieb James Kuyper:
Quoted text here. Click to load it

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

Site Timeline