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.
the beauty of C vs. assembly is its portability, in my view. and that's very important from a software point of view.
assembly (machine coding) can do everything C can do. However, it requires much higher hurdle on human capital, it requires more time for a project, and it is harder to reuse the code from one assembly to another, or to move the code from one chip to another.
What portability allows you to do is to take code developed and debugged on one project / chip and reuse the code on a new project. As you develop more and more in C, you will have built up a large library of code that can be ported to the next project, that you think with high/higher degree of confidence that it will work once plug'd in.
this becomes a huge competitive advantage for a software vendor: it allows you to develop a product sooner, cheaper, and with higher quality.
if you develop your code with portability in mind.
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.
That is a very, very, very big "if"!!
As Tamir's original quotation said (my emphasis added),
"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"
It is a common misapprehension that the mere fact of using 'C' - in and of itself - will inherently make your programs portable. It will not
Just as the mere fact of using Assembly - in and of itself - will not just magically make your code fast & compact.
"That is a very, very, very big "if"!!"
absolutely. for this strategy to yield fruit, the code will need to be developed with portability in mind.
just because you are using C doesn't mean you will write portable code.
no argument there whatsoever.