Welcome to the MISRA discussion forum

The actual rule is:

Quote:A project shall not contain instances of non-volatile variables being given values that are never subsequently used.

Hello,

MISRA C:2012 Rule 20.5 - #undef should not be used.

For the following code snippet, #undef is seen at line 5 and 8.
As Rule 20.5 complains for use of #undef, please let us know whether code at line 8, which is inactive code due to #else is Non-compliant or not according MISRA C:2012 Rule 20.5 ?


1. #define FLAG 100
2.
3. #ifdef FLAG
4. #define L 0
5. #undef L
6. #else
7. #define X 0
8. #undef X
9. #endif

Regards
Girish.M

Hello,

I've a problem when using the memset function, the error M10.1.1 is raised.
Error raised by the MISRA Tool used (RTRT):
line 12 row 30: Rule M10.1.1
Error: Implicit conversion of an integer expression to a different signedness is not allowed

Regarding the memset prototype,
void *memset (void *s, int c, size_t n);

The content of the test.h file is given see below:

The MISRA consortium, a world-leading collaboration between manufacturers, component suppliers and engineering consultancies, is celebrating 25 years since the landmark publication of Development Guidelines for Vehicle Based Software.

The guidelines, and the revisions and amendments that have followed, and the broader portfolio of MISRA documents published since then have underpinned significant improvements in vehicular software safety; and the success has seen the principles adopted by many other industries.

The MISRA consortium was conceived in the early 1990s as a project in the UK government’s “SafeIT” programme to develop guidelines for embedded software in road vehicle electronic systems. Membership now consists of members from other industries in the safety-related embedded systems world, alongside automotive companies.

The consortium started with eight core members in the funded project, and now consists of a board of ten in voluntary roles.

Landmark publications include the first edition of MISRA C in 1998, MISRA C:2004, guidelines for safety analysis in 2007, MISRA C++ :2008, MISRA C:2012 and guidelines for safety arguments in 2019.

In the late 1980s, the automotive industry had to adapt to more complex systems of embedded electronics in road vehicles. Starting with the publication of our first guidelines in 1994, MISRA has been at the forefront of making sure our safety standards have developed hand-in-hand with the technological breakthroughs in the industry.

Outside of the automotive sector, the MISRA guidelines have supported the development of renowned technological projects. The Joint Strike Fighter (JSF) project C++ Coding Standard and NASA Jet Propulsion Laboratory C Coding Standards, as used on the Mars Rover missions, are both based on MISRA guidelines.

A full press release is available at the main MISRA website at https://www.misra.org.uk/News/tabid/59/Default.aspx along with an infographic at https://www.misra.org.uk/MISRAHome/MISRA...fault.aspx

Hello,

Regarding the rule 20.11, the call of 'system' shall not be used. But In my current program, I'm creating process by using fork() and system() to start it.

What is the best solution to create process and start it in order to comply with MISRA C 2004 ?

By advance thanks for your answer.

Dear MISRA members,

Regarding the rule 6-6-3:
Does this rule only apply to for-loops or does it also apply to while-loops?

For references, the static analysis tool, Coverity reports a 6-6-3 rule violation when 'continue' statement is used in a while-loop.

Best Regards,
Goh

Hello,

Assuming that I have the following structure and enum:

Hello all,

I have some questions about Appendix H of MISRA C: 2012.

Appendix H states that C90 id and C99 id are based on C90 and C99 standard. Therefore, I thought there was only one C90 and C99 standard, but the reference lists multiple C90 and C99 standards. Which standard is used to create the table in Appendix H?

Also, C90 and C99 Standard are not assigned numbers such as C90 id and C99 id. How were the C90 id and C99 id numbering decided?

Hello,

In the MISRA-C:2012 essential type model, Rule 10.1 ("Operands shall not be of an innappropriate 'essential type'") allows to use essentially Boolean operands with the && and || logical operators, but disallows to use them with the & or | bitwise operators. However, as the && and || logical operators have short-circuit behavior (i.e. lazy evaluation, resulting effectively in an 'if ... else ...' expression), in some situations it may be preferred to use operators with eager evaluation (i.e. both operands are always evaluated, regardless of the value of the first parameter). For example, to avoid jump instructions in the generated code (the timing differences can be a problem for hard real-time systems, or even a side-channel timing attack), or just to make clear to the reviewer that the order of evaluation is not important.

As an essential Boolean can only hold the value 0 or 1, in my opinion it would be safe to allow the use of the & and | bitwise operators with essentially Boolean operands, in addition to the && and || logical operators. It's true that the order of evaluation won't be ensured when using bitwise operators (marked as unspecified behaviour by the standard), however this shouldn't be a problem when using them with just Boolean variables (i.e. instead of function calls returning a Boolean value) or expressions (or even Boolean literals); and futhermore Rule 13.2 already forbids side effects in expressions with multiple evaluation orders. Was the usage of the & and | bitwise operators disallowed with essentially Boolean operands due to problematic situations with the language (like the evaluation order), or either because it is not a typical C idiom? Do you think the usage of these & and | bitwise operators with Boolean operands can be considered safe (at least in some situations)?

Thanks in advance for any answer.

The MISRA Guidelines for Automotive Safety Arguments are now available to purchase from the MISRA webstore.

The guidelines provide clarity on how to develop Safety Arguments in line with existing standards such as ISO 26262, with a view to justifying that the risk associated with an automotive system is within industry norms. Types of evidence to support the argument are also suggested, as well as advice on practical application.

One of the specific motivations for developing these guidelines was to support the requirements for a safety case in ISO 26262. Since ISO 26262:2018 the safety case is now explicitly required to be based on an argument.