Welcome to the MISRA discussion forum

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

In Dir 2.1 , "A conforming compiler is permitted to produce an object module despite the presence of compilation errors."
I should explain this situation for the programmers, but I do not know any real compilers, producing an object module with the presence of compilation errors.
Do anyone know a compiler which can produce an object module with the presence of compilation errors?

Dr. Ogawa Kiyoshi.
@kaizen_nagoya
http://researchmap.jp/kaizen/MISRA-C/

Suppose I have: