Keith Thompson said:
Is "implementation" the word you want here? I think you're saying
that the *language* (or dialect) implemented by gcc may well become
the de-facto standard.
Yes... I though "oh bugger! That is the wrong word" after I read it back
when it had been posted.
Frankly, I hope that's not entirely true. To take just one example,
arithmetic on void*, particularly the way gcc implements it, is just
ugly (sizeof(void)==1???).
The problem is pragmatically speaking the Gcc dialect is very widely
spread. It is far more common than C99. Also there is a lot of freely
available source that uses the gcc dialect.
And, as I've mentioned, the standard itself doesn't provide much
guidance here. A conforming compiler must accept 12 levels of
pointers in *some* program, but not necessarily in *your* program.
However for many compilers they may not implement it. As there is no
legal requirement anywhere to use ISO C (ie C90- C99) compilers and as
very few do a full implementation you have the check what each one does.
For some compilers the level of nesting is difficult to do in the
architecture and as pragmatically many will not want more than 3 or 4
levels of indirection it *may* not be implemented to 12 levels.
But it is relevant to ask whether a given compiler conforms to the C90
(or C95) standard.
Yes and most do in the main but even so you have to check any deviations
from the standard. Getting high and mighty about the letter of the
standard will not save you if you do not read the limits of the compiler
you are using.
Incidentally this is why RULE 1 of MISRA-C is that you must use a fully
conforming C95 compiler. It is designed to get you to have to raise a
deviation for anything not matching the ISO C 95. Thus you have to
document and be aware of the limits (and extensions) of your compiler.
Knowing the limits of the tools you are using is far more important than
knowing chapter and verse on the ISO standard. (Which is a pity)
ISO says otherwise, but in real life, the C90
standard is still very relevant, and most compilers support a mode in
which they conform to C90, modulo bugs.
Absolutely this is why MISRA-C references C90+A1+TC1&2. In the real
world (ie not clc
where you have to write real safety critical
programs on real hardware from 8 to 128 bit MCU's the level of
conformance, or lack of, of the "C" compiler needs to be understood and
documented.
There were some discussions as to whether MISRA-C3 should reference C99.
Any suggestions?
It really depends on where the majority of embedded compilers will be in
2 years time, If the are still C95 ish that is where MISRA-C3 will
have to be as it is pointless doing a real world standard for tools
which don't exist in the mainstream. However if the majority suddenly
rush to C99 compliance then that is where MISRA-C 3 should be,