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?

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
  • It depends what you mean by "portability".
    Code developed for a 32-bit machine, littering some of it with preprocessor statements assuring it runs "correctly" on a 8-bit machine is not portable in my opinion.
    In think true portability is much more an issue at larger scale: software constructs conceived to achieve a goal, rather than the detailed code itself. Or in other words: the interface/algorithm, not the implementation details themselves (even that might not be portable, considering performance issues). I was lucky enough to have to port only from a LPC2478 to LPC17xx/18xx machines - but that is a no-brainer: even the peripherals are similar.

Reply
  • It depends what you mean by "portability".
    Code developed for a 32-bit machine, littering some of it with preprocessor statements assuring it runs "correctly" on a 8-bit machine is not portable in my opinion.
    In think true portability is much more an issue at larger scale: software constructs conceived to achieve a goal, rather than the detailed code itself. Or in other words: the interface/algorithm, not the implementation details themselves (even that might not be portable, considering performance issues). I was lucky enough to have to port only from a LPC2478 to LPC17xx/18xx machines - but that is a no-brainer: even the peripherals are similar.

Children
No data