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

Groups > comp.std.c > #6075 > unrolled thread

Making more of the C standard library mandatory for freestanding implementations

Back to article view | Back to comp.std.c

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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-07 06:08 -0700
              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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-08 08:38 -0700
                            Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-08 21:30 +0200
                              Re: Making more of the C standard library mandatory for freestanding implementations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-30 02:04 -0700
                            Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-08-04 10:58 +0200
                              Re: Making more of the C standard library mandatory for freestanding implementations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-04 07:35 -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 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
    Re: Making more of the C standard library mandatory for freestanding implementations upsidedown@downunder.com - 2020-05-07 08:59 +0300
    Re: Making more of the C standard library mandatory for freestanding implementations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-07 06:14 -0700
      Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-07 21:38 +0200
        Re: Making more of the C standard library mandatory for freestanding implementations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-08 12:03 -0700
          Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-08 21:15 +0200
          Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-08 21:27 +0200
            Re: Making more of the C standard library mandatory for freestanding implementations Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2020-05-15 15:13 +0200
          Re: Making more of the C standard library mandatory for freestanding implementations David Brown <david.brown@hesbynett.no> - 2020-05-09 00:25 +0200

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

#6075 — 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]

#6076

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]

#6077

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]

#6079

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]

#6080

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]

#6081

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]

#6083

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]

#6089

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]

#6097

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]

#6095

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> [...] 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.

I'm not sure that's right.  A freestanding implementation isn't
required to accept programs that use those headers, but I don't
see anything that would allow the implementation to violate their
specifications either.  Also, the Standard says implementations
may have extensions provided they do not alter the behavior of
/any/ strictly conforming program.  The definition of strictly
conforming program includes all library facilities, not just
those required of freestanding implementations.  Certainly a
freestanding implemention is free not to provide any library
facilities beyond its minimal required set, but AFAIK there isn't
any provision that would allow it to change the behavior of any
it does provide.

Please note, I'm not making an argument that the statement is
wrong.  But I do think the answer is not completely clearcut, and
the question is open to debate.

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

#6085

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]

#6086

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]

#6087

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]

#6088

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]

#6093

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]

#6098

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]

#6092

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]

#6102

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]

#6103

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]

#6104

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]

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

Back to top | Article view | comp.std.c

csiph-web