Welcome to the MISRA discussion forum

Hello,
I would like to confirm the following interpretation of the rule 8.5. The rule says that "Header files should be used to declare objects, functions, typedefs, and macros. Header files shall not contain or produce definitions of objects or functions (or fragment of functions or objects) that occupy storage."

I have seen a couple of alerts in code raised when the header file contains a macro that generates the "body of one function". My understanding is that this is the case where the "macro produces definitions of objects or functions", and that this is a violation to be corrected.

In a similar way, if the header file contains a #typedef for an struct, should it be considered a violation to this rule?

Thanks in advance.

The Rationale for rule 8.10 says that inline functions with external linkage are not to be used, because it is not defined whether the function will in fact be inlined, or the external definition will be called.

However, this is also not defined for static functions: "Making a function an inline function suggests that calls to the function be as fast as possible. The extent to which such suggestions are effective is implementation-defined." (I'm using a draft of the C99 standard, http://www.open-std.org/JTC1/sc22/wg14/w.../n1256.pdf and this is 6.7.4.5. Footnote 121 spells it out more clearly: "For example, an implementation might never perform inline substitution...".)

So the behaviour of static inline functions is undefined in the same way as inline functions with external linkage.

It has been suggested that inline functions defined in header files should be defined with static linkage. Paragraph 6.7.4.3 of the above pdf says external linkage cannot reference indentifiers with internal linkage, but paragraph 6.7.4.6 says that any function with internal linkage can be inlined. So if an inline function is declared static, it can have local static variables. But there will be a different instance of the inline function for each .c file which includes the header with the function's definition, and each would have its own static variables! Effectively, you have a function definition with a static variable, the value of which differs depending on where it is called from. This will surely be unexpected behaviour to some programmers, and is therefore dangerous.

Was this considered when specifying that all inline functions should be static? Or is the draft wildly different from the final C99 spec?

Hi everybody

I'm having a very hard time understanding why the following code gives me two errors regarding rule 11.3.

I have an incomplete struct type, as per Directive 4.8. I declare types for pointers to the hidden struct:

typedef struct s_EthBuf *TEthBuf;
typedef struct s_EthBuf const *CTEthBuf;

The actual type, and an instance of the type, are declared in the translation unit that also defines the functions which operate on it.

Some functions need to modify the contents of the object, so they take a parameter of type TEthBuf. Some do not; they take a parameter of type CTEthBuf.

PC-Lint tells me that assigning a TEthBuf pointer to a variable of type CTEthBuf, or const TEthBuf, or passing it to a function which takes CTEthBuf as its parameter type, violates rule 11.2.

So: if I have struct s_EthBuf X then the following get the warning the 11.2 is violated:
CTEthBuf a = X;
const TEthBuf b = X;
foo(x)
- where foo is declared as void foo(CTEthBuf buf);

But it's OK to do
TEthBuf c = X;

But the type is the same, it's just that foo() doesn't change anything in the object.

Is PC-Lint correct here, when it believes that the types are different from the point of view of rule 11.2?

Hi,

As far as I know the latest guideline for C++ is MISRA C++ 2008. According to the current Cpp conferences and its talks about modern C++, the increasing use of embedded linux and during some research C++11 / C++14 both provide many techniques that could be useful for embedded programming of safety critical systems. Please correct me if I'm wrong. To name a few features there are std::array, range-loops, constexpr, static_assert, enum class.

Are there any upcoming MISRA C++ guidelines planned in the near future covering those (C++11, …) standards ?

Thanks Daniel

#define NUM 9u
#define NUM2 8


/* gus32cmd is keyboard entry .numbers from 1 to 10*/

scanf("%d", &gus32cmd );

Switch(gus32cmd)
{
case:NUM
....
....
break;


case NUM2
..
..
break;

}

At lines case:NUM and case NUM2 I got following misra c error

"Rule 10.1 violated "implicit conversion of complex integer expression to a small sized integer is not allowed"
What correction I should do to avoid this error

Would the following example be compliant with rule #14.3?

Would the following examples be compliant with rule #8.3?

I have a header file MISRA_8.6.h, in which a variable is declared:

I have a question regarding rule 5.4: Which of the following #defines is violating this rule?