Welcome to the MISRA discussion forum

I'm not 100% sure on the interpretation of rule 6.2 when it comes to using "unsigned char" values as labels for switch case.

Example:

MISRA is pleased to announce that a set of code examples for MISRA C:2012 is available to download. These can be found in the “Resources” section of this Bulletin Board (free registration is required to access this area).

This set of files is intended to illustrate issues addressed by the MISRA C rules as expressed in MISRA C:2012 Guidelines for the use of the C language in critical systems. The code examples are mainly taken from the example sections in the MISRA C:2012 guidelines. It is not intended to be an exhaustive test suite and should not be used as such; however they may help users of the document understand compliant and non-compliant code.

A more comprehensive exemplar suite may be produced in the future.

The MISRA Autocode (AC) suite of documents will be undergoing a refresh in the near future to bring them up to date and align them with the new MISRA branding and other MISRA documents. MISRA AC GMG and MISRA AC SLSF will be reviewed and updated.

Based on the experience of MISRA AC contributors in using the current documents, the number and organization of documents is also up for consideration. In particular, it is believed that the code generation specific layer of guideline documents, where MISRA AC TL sits and where a MISRA AC EC offering could sit, is better supported by tool vendors themselves; the frequency of updates to auto-code generation tools has proved too high for a user-based body such as MISRA to keep track of, and it is in the interest of the tool vendors to provide guidelines directly to support their customers in meeting their respective industry software development standards.

MISRA AC TL is now seven years old and far removed from the current version of the tool offered by its vendor. This document will be deprecated and no longer supported by MISRA from 1 June 2014.

MISRA AC AGC will remain available and supported for legacy users of MISRA C:2004. It should be noted that the current version MISRA C:2012 integrates requirement for automatically-generated C code.

The MISRA Autocode (AC) suite of documents will be undergoing a refresh in the near future to bring them up to date and align them with the new MISRA branding and other MISRA documents. MISRA AC GMG and MISRA AC SLSF will be reviewed and updated.

Based on the experience of MISRA AC contributors in using the current documents, the number and organization of documents is also up for consideration. In particular, it is believed that the code generation specific layer of guideline documents, where MISRA AC TL sits and where a MISRA AC EC offering could sit, is better supported by tool vendors themselves; the frequency of updates to auto-code generation tools has proved too high for a user-based body such as MISRA to keep track of, and it is in the interest of the tool vendors to provide guidelines directly to support their customers in meeting their respective industry software development standards.

MISRA AC TL is now seven years old and far removed from the current version of the tool offered by its vendor. This document will be deprecated and no longer supported by MISRA from 1 June 2014.

MISRA AC AGC will remain available and supported for legacy users of MISRA C:2004. It should be noted that the current version MISRA C:2012 integrates requirement for automatically-generated C code.

The MISRA Autocode (AC) suite of documents will be undergoing a refresh in the near future to bring them up to date and align them with the new MISRA branding and other MISRA documents. MISRA AC GMG and MISRA AC SLSF will be reviewed and updated.

Based on the experience of MISRA AC contributors in using the current documents, the number and organization of documents is also up for consideration. In particular, it is believed that the code generation specific layer of guideline documents, where MISRA AC TL sits and where a MISRA AC EC offering could sit, is better supported by tool vendors themselves; the frequency of updates to auto-code generation tools has proved too high for a user-based body such as MISRA to keep track of, and it is in the interest of the tool vendors to provide guidelines directly to support their customers in meeting their respective industry software development standards.

MISRA AC TL is now seven years old and far removed from the current version of the tool offered by its vendor. This document will be deprecated and no longer supported by MISRA from 1 June 2014.

MISRA AC AGC will remain available and supported for legacy users of MISRA C:2004. It should be noted that the current version MISRA C:2012 integrates requirement for automatically-generated C code.

The MISRA Autocode (AC) suite of documents will be undergoing a refresh in the near future to bring them up to date and align them with the new MISRA branding and other MISRA documents. MISRA AC GMG and MISRA AC SLSF will be reviewed and updated.

Based on the experience of MISRA AC contributors in using the current documents, the number and organization of documents is also up for consideration. In particular, it is believed that the code generation specific layer of guideline documents, where MISRA AC TL sits and where a MISRA AC EC offering could sit, is better supported by tool vendors themselves; the frequency of updates to auto-code generation tools has proved too high for a user-based body such as MISRA to keep track of, and it is in the interest of the tool vendors to provide guidelines directly to support their customers in meeting their respective industry software development standards.

MISRA AC TL is now seven years old and far removed from the current version of the tool offered by its vendor. This document will be deprecated and no longer supported by MISRA from 1 June 2014.

MISRA AC AGC will remain available and supported for legacy users of MISRA C:2004. It should be noted that the current version MISRA C:2012 integrates requirement for automatically-generated C code.

I have a pure virtual function like
virtual void OnEvent(EventName event, State& superState) = 0;

For some of the derived classes, the implementation uses both of the the parameters. For others, the parameters are not used at all.

Is this acceptable?

Does this rule prevent "using namespace ..." in a header file, if, it is inside a namespace?

e.g. is it ok to do this in the header...
namespace ComponentX
{
using namespace BasicTypes;
class AClass
{
public:
bool_t IsActive(void);
};
}
}

or would i have to do this...
BasicTypes::bool_t IsActive(void);

I have a question for the Rule8.13.

The rule8.13 is
A pointer should point to a const-qualified type whenever possible

A pointer parameter in a function prototype should be declared as pointer to const if the pointer is not used to modify the addressed object


However,
target of the rule16.7 on MISRAC-2004 is "pointer parameter in a fuction".

Why do you delete "pointer parameter in a function"?

Please tell me the reason.


Best Regards,
Kumiko Itoh

I have a question for the Rule8.6 exmaple.

Your guideline has a following example.
/* file3.c */
int16_t j; /* Tentative definition */
int16_t j=1; /* Compliant - external definition */

I make the next exapmle.
Is it correct?

/* file3_2.c */
int16_t m=1; /* Compliant - external definition */　←is it correct?
int16_t m; /* declaration */ ←is it correct?


Best Regards,
Kumiko Itoh