• State Not Answered
  • Locked Locked
  • Replies 53 replies
  • Subscribers 21 subscribers
  • Views 14732 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

What does the C standard say about portability?

Tamiryan Michael

Hello,

See here:

www.open-std.org/.../C99RationaleV5.10.pdf

Is it possible that "Jack Sprat", the staunch defender of the C standard as the ultimate reference when writing programs, missed the following statement?

C code can be non-portable.  Although it strove to give programmers the opportunity to write
truly portable programs, the C89 Committee did not want to force programmers into writing
portably, to preclude the use of C as a “high-level assembler”:  the ability to write machine-
35  specific code is one of the strengths of C.  It is this principle which largely motivates drawing the
distinction between strictly conforming program and conforming program (§4).

this is precisely what Per Westermark has been saying.
Exactly what Erik Malund has been saying.
Remember: Jack Sprat claims often that writing a program that complies with the C standard is a GUARANTEE for its correct functioning.

Parents
  • 0 in reply to ²erik malund

    'what is stated is a thing that must be done at the conception of the code for the original processor.'

    it doesn't have to be done at the conception; but it is best done at the conception.

    there are different kinds of portability:

    1) across platform portability: many tasks are non-hardware specific, like doing fft, for example (without using hardware). a pid library for example would be another good example here.

    2) across family portability: some tasks are hardware specific to a family of chips. their portability is likely limited to the interface - you always call i2c_send() to send a byte over i2c, but different platforms may have their own ways of performing that task. etc. those things that are specific to that family / hardware obviously isn't portable and have to be recreated on a new hardware. But portability insulates the higher layers from being (materially) rewritten.

    then there are pieces of code that are not going to be portable regardless of what you do. part of our job is to minimize that portion.

Reply
  • 0 in reply to ²erik malund

    'what is stated is a thing that must be done at the conception of the code for the original processor.'

    it doesn't have to be done at the conception; but it is best done at the conception.

    there are different kinds of portability:

    1) across platform portability: many tasks are non-hardware specific, like doing fft, for example (without using hardware). a pid library for example would be another good example here.

    2) across family portability: some tasks are hardware specific to a family of chips. their portability is likely limited to the interface - you always call i2c_send() to send a byte over i2c, but different platforms may have their own ways of performing that task. etc. those things that are specific to that family / hardware obviously isn't portable and have to be recreated on a new hardware. But portability insulates the higher layers from being (materially) rewritten.

    then there are pieces of code that are not going to be portable regardless of what you do. part of our job is to minimize that portion.

Children
No data