Welcome to the MISRA discussion forum

Question: What is the character set referred to in Rule 3.2?

Answer: MISRA C Steering Team

There are two character sets.
The source code is written in one character set.
The program can execute with input/output in a second character set.
These may or may not be the same.
Both the basic source character set and the basic execution character sets shall be documented.
This rule allows free choice of character sets for coding and execution. This use shall be documented.

Question: Is Rule 20.1 applicable to \"defined\"?

(a) We presume that \"#define defined (10)\" will be in violation of Rule 20.1.

(b) If our presumption is correct, then which of \"reserved identifier\", \" macro\" or \"function\" will \"defined\" be?
We could not find the answer in ISO/IEC 9899:1990. Is it described somewhere in COR1, COR2 or AMD1?

Answer: MISRA C Steering Team 7/9/2005

(a) YES - defined is included in the text under the rule.

(b) defined is listed under 6.8.8 Predefined Macro Names.
It is also listed in Appendix G: Undefined Behaviour 54.

Question:

Is it correct to think that a keyword is out of the scope of Rule 20.1?

For example, \"#define int (10)\" violates Rule 19.4, doesn't it?

Answer: MISRA C Steering Team 7/9/2005

Keywords (as defined in 6.1.1) shall be considered to be in the scope of 20.1.
This is detailed in the supporting text and will be clarified in the Technical Corrigendum.

#define int (10)

This is not a violation of 19.4.

19.4 is concerned with the replacement text of a macro, and not its name.

Question 2: Interpretation of \"not be defined, redefined\"

a) Does it mean that \"#define\" is not allowed?

b) Is it not allowed to define as an object or a function, either?

Answer: MISRA C Steering Team clarification 7/9/2005

(a) YES - To define an object or a function with the name of a reserved identifier is prohibited under rule 20.2.

(b) YES - To #define macros with the name of a reserved identifier is prohibited.

Question:

Question 1: Interpretation of \"Reserved identifiers, macros and functions in the standard library\"

Does this phrase mean
a) \"Reserved identifiers
AND
macros in the standard library
AND
functions in the standard library\"
or
b) \"Reserved identifiers in the standard library
AND
macros in the standard library
AND
functions in the standard library\" ?

It seems that in case of a) above, \"#define __ABC (10)\" violates Rule 20.1 whereas it does not in case of b), because \"__ABC\", which is a reserved identifier, is not in the standard library. Moreover, it is not guaranteed that all of \"__LINE__, __FILE__, __DATE__, __TIME__, __STDC__ \"
are in the standard library. If not in the standard library, it is presumed that they can be \"defined, redefined or undefined\". Which interpretation should we take, a) or b) ?

MISRA C Steering Team Answer (7/9/2005)
Option A.
Reserved identifiers are defined by ISO/IEC 9899:1990 sections 7.1.3 Reserved Identifiers, 7.13 Future library directions and 6.8.8 Predefined Macro Names.
Macros in the standard library are examples of reserved identifiers.
Functions in the standard library are examples of reserved identifiers.

Any identifier in the standard library is an example of reserved identifiers.

I've updated the phpbb code today to fix some security concerns.

If you spot something not working, please let me know.

--------------
IT Manager

In the beginning \"C\" was considered unsuitable for safety critical and safety related systems, however, it was so used ...

In 1998, as a response to this situation, MISRA produced MISRA C, a set of guidelines to aid the development of safety related systems in \"C\" in the automotive world. Since then, MISRA C has been adopted by the wider embedded systems community and has become the dominant, international coding guidelines for the use of \"C\" in critical systems. The MISRA C guidelines are widely accepted as fulfilling the requirements for a language subset as required by both the 1994 MISRA \"Development guidelines for vehicle based software\" and IEC 61508.

Things move on, and now C++ is in the position once held by \"C\"; many people believe that it should not be used for critical systems, but its use within the field is growing and that growth is without a common set of guidelines.

MISRA has recently started work on the production of a set of guidelines for the use of C++ in critical systems, the output of which will be a set of guidelines similar to those that were produced for \"C\".

The work, like other MISRA work, will be done on a voluntary basis. As such, MISRA is currently looking for 3 to 5 additional people to participate in the development of MISRA C++. We are looking for dedicated people who can contribute to a two day, focused working meeting once a month and who are also willing to put in effort \"off-line\".

If you are interested in taking part, please send your details to the chairman of the working group, Chris Tapp (chairman (at) misra-cpp.org). A brief note on your background would be appreciated, especially as we expect to receive too many volunteers and will have to make some tough choices!

It has been reported that the mail digest system has not been working for some time. My apologies to all who have been affected by this outage.

When we moved the MISRA-C2 website to a new server, the batch job to mail out the digest each hour was omitted. It has now been reinstated, and appears to be mailing out digests OK.

You can subscribe/unsubscribe to digests of the forum using the link at the top of the page. Set the options to receive the digests of what you want, when you want it and click on the \"update\" button. It should then mail out as you request. Note that the hour is GMT, so you'll need to take that into account when electing the time to receive the digests.

Thanks

In order to make this bulletin board more user-friendly and accessible, it is no longer necessary to log in to view posts. It is still necessary to be a registered user and to log in to make posts.

If you have any comments or concerns please contact the forum admin.

Whenever you change the definition of an array, the corresponding declaration for external linkage may need to be adapted (different size of array). This is error-prone since the declaration usually is included in a file different from the file with the definition. As a consequence, the code becomes inconsistent and more difficult to understand.
Moreover, the size information in the declaration with external linkage is redundant. Compilers usually ignore it.
So what are the benefits of having rule 8.12 classified as a \"required\" rule?