Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29611 > unrolled thread

Making more of the C standard library mandatory for freestanding implementations

Back to article view | Back to comp.arch.embedded

Contents

  Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-06 18:19 +0200
    Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-06 16:47 +0000
      Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-06 19:16 +0200
        Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-06 18:10 +0000
          Re: Making more of the C standard library mandatory for freestanding implementations James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-06 15:10 -0400
            Re: Making more of the C standard library mandatory for freestanding implementations Richard Damon <Richard@Damon-Family.org> - 2020-05-06 16:08 -0400
              Re: Making more of the C standard library mandatory for freestanding implementations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-06 13:22 -0700
                Re: Making more of the C standard library mandatory for freestanding implementations Richard Damon <Richard@Damon-Family.org> - 2020-05-06 22:29 -0400
                  Re: Making more of the C standard library mandatory for freestanding implementations David Brown <david.brown@hesbynett.no> - 2020-05-07 15:43 +0200
              Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-06 22:36 +0200
                Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-06 20:57 +0000
                Re: Making more of the C standard library mandatory for freestanding implementations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-05-06 23:25 +0200
                  Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-06 21:34 +0000
                    Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-07 10:17 +0200
                      Re: Making more of the C standard library mandatory for freestanding implementations Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-05-07 18:45 +0300
                  Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-07 10:16 +0200
                    Re: Making more of the C standard library mandatory for freestanding implementations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-05-07 21:39 +0200
                      Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-07 21:44 +0200
                        Re: Making more of the C standard library mandatory for freestanding implementations Paul Rubin <no.email@nospam.invalid> - 2020-05-07 12:54 -0700
            Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-06 22:34 +0200
              Re: Making more of the C standard library mandatory for freestanding implementations upsidedown@downunder.com - 2020-05-07 09:13 +0300
              Re: Making more of the C standard library mandatory for freestanding implementations Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-05-07 18:47 +0300
                Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-07 15:51 +0000
                  Re: Making more of the C standard library mandatory for freestanding implementations Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-05-08 10:09 +0300
          Re: Making more of the C standard library mandatory for freestanding implementations Stefan Reuther <stefan.news@arcor.de> - 2020-05-07 18:00 +0200
            Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-07 17:17 +0000
              Re: Making more of the C standard library mandatory for freestanding implementations David Brown <david.brown@hesbynett.no> - 2020-05-07 20:23 +0200
              Re: Making more of the C standard library mandatory for freestanding implementations Stefan Reuther <stefan.news@arcor.de> - 2020-05-08 17:33 +0200
                Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-08 15:56 +0000
                  Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-08 20:31 +0200
                    Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-08 18:53 +0000
                      Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-08 21:32 +0200
                        Re: Making more of the C standard library mandatory for freestanding implementations David Brown <david.brown@hesbynett.no> - 2020-05-09 00:13 +0200
                          Re: Making more of the C standard library mandatory for freestanding implementations Richard Damon <Richard@Damon-Family.org> - 2020-05-08 18:45 -0400
                            Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-08 22:59 +0000
                              Re: Making more of the C standard library mandatory for freestanding implementations Richard Damon <Richard@Damon-Family.org> - 2020-05-09 08:29 -0400
                            Re: Making more of the C standard library mandatory for freestanding implementations David Brown <david.brown@hesbynett.no> - 2020-05-09 16:10 +0200
                              Re: Making more of the C standard library mandatory for freestanding implementations Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-05-09 20:15 +0300
                                Re: Making more of the C standard library mandatory for freestanding implementations David Brown <david.brown@hesbynett.no> - 2020-05-10 12:37 +0200
                  Re: Making more of the C standard library mandatory for freestanding implementations Stefan Reuther <stefan.news@arcor.de> - 2020-05-09 09:52 +0200
      Re: Making more of the C standard library mandatory for freestanding implementations Florian Weimer <fw@deneb.enyo.de> - 2020-05-08 18:48 +0200
        Re: Making more of the C standard library mandatory for freestanding implementations Andrew Smallshaw <andrews@sdf.org> - 2020-05-08 17:01 +0000
          Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-08 20:05 +0200

Page 1 of 3  [1] 2 3  Next page →

#29611 — 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

[toc] | [next] | [standalone]

#29612

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

[toc] | [prev] | [next] | [standalone]

#29613

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

[toc] | [prev] | [next] | [standalone]

#29614

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

[toc] | [prev] | [next] | [standalone]

#29615

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?

[toc] | [prev] | [next] | [standalone]

#29616

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.

[toc] | [prev] | [next] | [standalone]

#29617

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 */

[toc] | [prev] | [next] | [standalone]

#29623

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.

[toc] | [prev] | [next] | [standalone]

#29627

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.

[toc] | [prev] | [next] | [standalone]

#29619

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

[toc] | [prev] | [next] | [standalone]

#29620

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

[toc] | [prev] | [next] | [standalone]

#29621

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.

[toc] | [prev] | [next] | [standalone]

#29622

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

[toc] | [prev] | [next] | [standalone]

#29626

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.

[toc] | [prev] | [next] | [standalone]

#29628

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

[toc] | [prev] | [next] | [standalone]

#29625

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.

[toc] | [prev] | [next] | [standalone]

#29634

Am 07.05.2020 um 10:16 schrieb Philipp Klaus Krause:
> 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. 

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.

[toc] | [prev] | [next] | [standalone]

#29635

Am 07.05.20 um 21:39 schrieb Hans-Bernhard Bröker:
> Am 07.05.2020 um 10:16 schrieb Philipp Klaus Krause:
>> 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. 
> 
> 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.

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.

[toc] | [prev] | [next] | [standalone]

#29636

Philipp Klaus Krause <pkk@spth.de> writes:
> 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.

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.

[toc] | [prev] | [next] | [standalone]

#29618

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web