MISRA-C:2010 (version 3)

[Chris Hills]

The MISRA-C team has to make a decision: should it move from Referencing
C95 (9899:1990+A1+RC1+TC2) to referencing C99 for the next MISRA-C
(version 3)

In the real world (especially embedded, safety-critical and
high-integrity circles) there are no C99 compilers in use as on
September 2007. They are C95+.

Any thoughts from anyone involved in writing compilers? Either to the NG
or to my email address. Yes, I have asked most of the main embedded
compiler companies I have contacts for (about 15 of them so far) .

 

[Bart van Ingen Schenau]

The MISRA-C team has to make a decision: should it move from
Referencing
C95 (9899:1990+A1+RC1+TC2) to referencing C99 for the next MISRA-C
(version 3)

In the real world (especially embedded, safety-critical and
high-integrity circles) there are no C99 compilers in use as on
September 2007. They are C95+.

Any thoughts from anyone involved in writing compilers? Either to the
NG
or to my email address. Yes, I have asked most of the main embedded
compiler companies I have contacts for (about 15 of them so far) .

Two points.
1. Personally, I have never felt a need for any of the features that
were introduced in C(( for my embedded work. And judging by your
survey, I was not the only one.

2. As I know the MISRA standard to be rather restrictive, have you
investigated if there would be any language constructs from C99 that
the MISRA standard would allow you to use?

Bart v Ingen Schenau

 

[Chris Hills]

Two points.
1. Personally, I have never felt a need for any of the features that
were introduced in C(( for my embedded work. And judging by your
survey, I was not the only one.

All the embedded compiler companies report no requirement for C99 from
(serious) customers.

2. As I know the MISRA standard to be rather restrictive, have you
investigated if there would be any language constructs from C99 that
the MISRA standard would allow you to use?

There is AFAIK quit a large subset of C99 that is the same a s C90 so we
could do a common subset.

 

[Boudewijn Dijkstra]

Op Mon, 10 Sep 2007 20:50:50 +0200 schreef Bart van Ingen Schenau

Two points.
1. Personally, I have never felt a need for any of the features that
were introduced in C

Really? Nothing useful since 1978?

(( for my embedded work. And judging by your
survey, I was not the only one.

2. As I know the MISRA standard to be rather restrictive, have you
investigated if there would be any language constructs from C99 that
the MISRA standard would allow you to use?

Good point. This could mean that it is insensible to demand full C99
compliance.

 

[Keith Thompson]

Op Mon, 10 Sep 2007 20:50:50 +0200 schreef Bart van Ingen Schenau
<[email protected]>: [...]

1. Personally, I have never felt a need for any of the features that
were introduced in C

Really? Nothing useful since 1978?

(( for my embedded work.

I'm sure that "C((" was a typo for "C99". Note that '(' is shift-'9',
at least on my keyboard.

 

[Bart van Ingen Schenau]

There is AFAIK quit a large subset of C99 that is the same a s C90 so
we could do a common subset.

There should be a very large common subset between C99 and C90, because
C99 did not define a new language.
The only feature of C90 that I know to be absent from C99 is 'implicit
int'. AFAIK, using this feature is already forbidden by MISRA.

To my knowledge, the subset of C that MISRA sanctions already falls
entirely within the common subset of C90 and C99.
Therefor, the only reason that I can think of for switching standards
that MISRA is based on, is because the C99 standard provides some new
feature that MISRA also wants to allow.

As there are no compilers that support C99, a middle way can be that
MISRA allows you to use either a C90, a C95 or C99 compiler, where the
allowable feature-set depends on the standard that the compiler
conforms to (or the one that the compiler is configured to follow).
For example, wide-character support could only be used if the compiler
conforms to C95 or C99.

Bart v Ingen Schenau

 

[Bart van Ingen Schenau]

Op Mon, 10 Sep 2007 20:50:50 +0200 schreef Bart van Ingen Schenau
<[email protected]>: [...]

1. Personally, I have never felt a need for any of the features that
were introduced in C

Really? Nothing useful since 1978?

(( for my embedded work.

I'm sure that "C((" was a typo for "C99". Note that '(' is shift-'9',
at least on my keyboard.

That was indeed a typo. Thanks for catching it.

Bart v Ingen Schenau

 

[Keith Thompson]

There should be a very large common subset between C99 and C90, because
C99 did not define a new language.
The only feature of C90 that I know to be absent from C99 is 'implicit
int'. AFAIK, using this feature is already forbidden by MISRA.

To my knowledge, the subset of C that MISRA sanctions already falls
entirely within the common subset of C90 and C99.
Therefor, the only reason that I can think of for switching standards
that MISRA is based on, is because the C99 standard provides some new
feature that MISRA also wants to allow.

If you want to limit yourself to the common subset of C90 and C99, you
also have to avoid using any of the new C99 keywords as identifiers.

As there are no compilers that support C99, a middle way can be that
MISRA allows you to use either a C90, a C95 or C99 compiler, where the
allowable feature-set depends on the standard that the compiler
conforms to (or the one that the compiler is configured to follow).
For example, wide-character support could only be used if the compiler
conforms to C95 or C99.

There are a very few compilers that support C99, and a somewhat larger
number that support much of C99. It *might* be possible to define a
C99 subset that's supported widely enough for your purposes.
(Actually it almost certainly is possible, if the C99 subset is just
C90 or C95, but I'm referring to new C99 features.)

On the other hand, enforcing the subset is going to be difficult.
Many compilers support "//" comments and long long, but only in a mode
in which they won't diagnose many other deviations from the C90
standard.

 

[Al Balmer]

As there are no compilers that support C99

There are a few, and there are more which support most of C99.

 

[Ark Khasin]

All the embedded compiler companies report no requirement for C99 from
(serious) customers.

There is AFAIK quit a large subset of C99 that is the same a s C90 so we
could do a common subset.

Are the /serious/ customers those with the most serious purse? They
might not be the most serious technically...
Some organizations are bent on MISRA; if it required (most of) C99, that
would put pressure on the compiler vendors.

I happen to have written a (firmware) coding standard for a customer of
mine (and it proved to be good enough for IEC 61508 SIL 2); it was based
on MISRA 2004 with rules cherry-picked as my colleagues and I saw
appropriate. And I sorely missed a few C99 things.

1. Designated initializers. They finally made static initialization
readable and better maintainable - the issue greatly under-appreciated.
Many compilers support this (perhaps in anticipation of C++ move).

2. restrict keyword. If my compiler doesn't support it, I could
#define restrict /* nothing */
and at least my intention is clear (e.g. to the reviewer)

3. somebody has to proscribe compound literals as RAM gobblers. Hard to
do so without referencing C99.

4. stdint.h and friends. If I don't have them, I can create them for my
CPU once; at least I'd be speaking a common language with C99 types.

5. / and % finally got defined behavior; a non-compliant compiler could
just be declared non-MISRA-compliant.

6. long long and such...

That is to say, MISRA-obeying C code already looks like C99 albeit
without C99-specific features. The latter can be referenced, feature by
feature, as "if available" and/or "equivalent implementation
required/advised"

That's my $0.02F

-- Ark

 

[Ark Khasin]

Are the /serious/ customers those with the most serious purse? They
might not be the most serious technically...
Some organizations are bent on MISRA; if it required (most of) C99, that
would put pressure on the compiler vendors.

I happen to have written a (firmware) coding standard for a customer of
mine (and it proved to be good enough for IEC 61508 SIL 2); it was based
on MISRA 2004 with rules cherry-picked as my colleagues and I saw
appropriate. And I sorely missed a few C99 things.

1. Designated initializers. They finally made static initialization
readable and better maintainable - the issue greatly under-appreciated.
Many compilers support this (perhaps in anticipation of C++ move).

2. restrict keyword. If my compiler doesn't support it, I could
#define restrict /* nothing */
and at least my intention is clear (e.g. to the reviewer)

3. somebody has to proscribe compound literals as RAM gobblers. Hard to
do so without referencing C99.

4. stdint.h and friends. If I don't have them, I can create them for my
CPU once; at least I'd be speaking a common language with C99 types.

5. / and % finally got defined behavior; a non-compliant compiler could
just be declared non-MISRA-compliant.

6. long long and such...

That is to say, MISRA-obeying C code already looks like C99 albeit
without C99-specific features. The latter can be referenced, feature by
feature, as "if available" and/or "equivalent implementation
required/advised"

That's my $0.02F

-- Ark

Oops! Completely forgot!
7. Cannot live without static inline!
-- Ark

 

[CBFalconer]

Oops! Completely forgot!
7. Cannot live without static inline!

A good summary. I think the various users should realize that, in
general, embedded systems don't have to handle the variety of
applications and methods that a hosted system needs, so the C
systems can be much more specialized. Part of the art is to pick a
processor and code generation software that is compatible with your
end application. Of course the closer such a system is to meeting
the standard (C90 or C99) the easier the coding is, but the more
expensive the hardware (and system software) may be.

 

[Marco]

On the other hand, enforcing the subset is going to be difficult.
Many compilers support "//" comments and long long, but only in a mode
in which they won't diagnose many other deviations from the C90
standard.

I don't have a copy of MISRA 2004. Does it restrict the use of "//"
comments and long long (of course indirectly as typedef 64 bit types,
etc) since it still uses C90 as a base?

If it does, MISRA 2010 should relax this.

 

[Marco]

I don't have a copy of MISRA 2004. Does it restrict the use of "//"
comments and long long (of course indirectly as typedef 64 bit types,
etc) since it still uses C90 as a base?

If it does, MISRA 2010 should relax this.

almost forgot also should allow the C99 bool

 

[Chris Hills]

I don't have a copy of MISRA 2004. Does it restrict the use of "//"
comments
Yes

and long long

Doesn't mention it.

(of course indirectly as typedef 64 bit types,
etc) since it still uses C90 as a base?

64 bits are still available in some implementations The Alpha chip

If it does, MISRA 2010 should relax this.

It is likely MISRA-C:2010 will be 99- rather than C95+

 

[Chris Hills]

almost forgot also should allow the C99 bool

You won't believe the fun we had with bool

I think you can probably say that // long long and bool will be in
MISRA-C:2010 and permitted

Since the MISRA-C team started on C2 in 2000 the embedded compiler
market has moved from a C95(plus) basis to a C99 minus basis.

You only have to look at who is using the C99 EDG front end and C99
Dinkumware libraries. Now compilers tend to be using C99 parts and
working to wards implementing them rather than tools based on a C90
core.

 

[Spaka]

All the embedded compiler companies report no requirement for C99 from
(serious) customers.


There is AFAIK quit a large subset of C99 that is the same a s C90 so
we could do a common subset.

As I understand it C99 is not compatible with C90.
Preprocessor arithmetic in C90 is done as long but in C99 it is done in
int.
Thus:

#define TEST 32767+1

....result in different values for C90 and C99 on 16-bit systems!

Is my understanding correct?

 

[Keith Thompson]

As I understand it C99 is not compatible with C90.
Preprocessor arithmetic in C90 is done as long but in C99 it is done in
int.
Thus:

#define TEST 32767+1

...result in different values for C90 and C99 on 16-bit systems!

Is my understanding correct?

No.

In C99, arithmetic expressions in #if directives are done using the
equivalent of intmax_t or uintmax_t (the widest signed and unsigned
integral types available on the implementation, which must be at least
64 bits).

 

[Walter Roberson]

As I understand it C99 is not compatible with C90.
Preprocessor arithmetic in C90 is done as long but in C99 it is done in
int.
Thus:

#define TEST 32767+1

...result in different values for C90 and C99 on 16-bit systems!

Is my understanding correct?

#define TEST 32767+1

does not do any preprocessor arithmetic: it defines TEST as
the token sequence 32767 + 1 all unevaluated.

 

[Spaka]

(e-mail address removed)-cnrc.gc.ca (Walter Roberson) wrote in @canopus.cc.umanitoba.ca:

#define TEST 32767+1

does not do any preprocessor arithmetic: it defines TEST as
the token sequence 32767 + 1 all unevaluated.

Yes, I realise my mistake.
The arithmetic is done in the #if statement.
However, after re-reading the standard, I now understand that C90
and C99 can be seen as performing the same function.

I can to the wrong conclusion when I can across a broken C90 compiler
that evaluated the constant_expression as an int and I mis-read the
standard and assumed intmax_t and uintmax_t were referring to the int
type and this I assumed that the compiler had implemented some C99
functionality!!!
How silly am I? ( no need to answer )

BTW. I find it surprising how many compiler don't even comply with
C90, the above is a classic example.
I'm involved in generating embedded code to MISRA standards and
have still not used a compiler that is not broken in some way.

Morale: don't trust the compiler.
Run your own validation on the compiler and modify your programming
rules to avoid the broken bits!

Anyway, Thanks for the clarification.