By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,921 Members | 1,493 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,921 IT Pros & Developers. It's quick & easy.

MISRA-C:2010 (version 3)

P: n/a
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) .

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Sep 10 '07 #1
Share this Question
Share on Google+
18 Replies


P: n/a
Chris Hills wrote:
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
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
Sep 10 '07 #2

P: n/a
In article <23****************@ingen.ddns.info>, Bart van Ingen Schenau
<ba**@ingen.ddns.infowrites
>Chris Hills wrote:
>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.
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.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Sep 11 '07 #3

P: n/a
Op Mon, 10 Sep 2007 20:50:50 +0200 schreef Bart van Ingen Schenau
<ba**@ingen.ddns.info>:
Chris Hills wrote:
>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
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.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
Sep 11 '07 #4

P: n/a
"Boudewijn Dijkstra" <bo*******@indes.comwrites:
Op Mon, 10 Sep 2007 20:50:50 +0200 schreef Bart van Ingen Schenau
<ba**@ingen.ddns.info>:
[...]
>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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 11 '07 #5

P: n/a
Chris Hills wrote:
In article <23****************@ingen.ddns.info>, Bart van Ingen
Schenau <ba**@ingen.ddns.infowrites
>>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.
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
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
Sep 11 '07 #6

P: n/a
Keith Thompson wrote:
"Boudewijn Dijkstra" <bo*******@indes.comwrites:
>Op Mon, 10 Sep 2007 20:50:50 +0200 schreef Bart van Ingen Schenau
<ba**@ingen.ddns.info>:
[...]
>>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
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
Sep 11 '07 #7

P: n/a
Bart van Ingen Schenau <ba**@ingen.ddns.infowrites:
Chris Hills wrote:
>In article <23****************@ingen.ddns.info>, Bart van Ingen
Schenau <ba**@ingen.ddns.infowrites
>>>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.
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 11 '07 #8

P: n/a
On Tue, 11 Sep 2007 17:30:11 +0200, Bart van Ingen Schenau
<ba**@ingen.ddns.infowrote:
>As there are no compilers that support C99
There are a few, and there are more which support most of C99.

--
Al Balmer
Sun City, AZ
Sep 12 '07 #9

P: n/a
Chris Hills wrote:
>
All the embedded compiler companies report no requirement for C99 from
(serious) customers.
<snip>
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


Sep 19 '07 #10

P: n/a
Ark Khasin wrote:
Chris Hills wrote:
>>
All the embedded compiler companies report no requirement for C99 from
(serious) customers.
<snip>
>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
Oops! Completely forgot!
7. Cannot live without static inline!
-- Ark
Sep 20 '07 #11

P: n/a
Ark Khasin wrote:
Ark Khasin wrote:
>Chris Hills wrote:
>>>
All the embedded compiler companies report no requirement for
C99 from (serious) customers.
<snip>
>>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...

Oops! Completely forgot!
7. Cannot live without static inline!
>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"
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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 20 '07 #12

P: n/a
On Sep 11, 1:54 pm, Keith Thompson <ks...@mib.orgwrote:
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.

Oct 13 '07 #13

P: n/a
On Oct 13, 5:15 am, Marco <prenom_no...@yahoo.comwrote:
On Sep 11, 1:54 pm, Keith Thompson <ks...@mib.orgwrote:
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.
almost forgot also should allow the C99 bool


Oct 13 '07 #14

P: n/a
In article <11**********************@q3g2000prf.googlegroups. com>, Marco
<pr**********@yahoo.comwrites
>On Sep 11, 1:54 pm, Keith Thompson <ks...@mib.orgwrote:
>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
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 Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 13 '07 #15

P: n/a
In article <11**********************@v29g2000prd.googlegroups .com>,
Marco <pr**********@yahoo.comwrites
>On Oct 13, 5:15 am, Marco <prenom_no...@yahoo.comwrote:
>On Sep 11, 1:54 pm, Keith Thompson <ks...@mib.orgwrote:
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.

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.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 13 '07 #16

P: n/a
Chris Hills <ch***@phaedsys.orgwrote in
news:ST**************@phaedsys.demon.co.uk:
In article <23****************@ingen.ddns.info>, Bart van Ingen
Schenau <ba**@ingen.ddns.infowrites
>>Chris Hills wrote:
>>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.

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.

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?
Apr 1 '08 #17

P: n/a
Spaka <me********@yahoo.comwrites:
[...]
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).

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 1 '08 #18

P: n/a
In article <Xn****************************@69.16.176.253>,
Spaka <me********@yahoo.comwrote:
>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.

--
"I like to build things, I like to do things. I am having
a lot of fun." -- Walter Chrysler
Apr 1 '08 #19

This discussion thread is closed

Replies have been disabled for this discussion.