Welcome to the MISRA discussion forum

typedef unsigned char bool;
bool sensor_status;

if(sensor_status) /*Rule 13.2*/
{
....
}
Is this a violation of rule 13.2 or could it be considered as effectively boolean ( Boolean by enforcement ).

The unused macro in "header" files are also a violation of this rule. explanation below:

File.h:
================
#define abc 10
================

Case1:
File1.c include file.h but does not use abc
Is this a violation.

Case2:
File1.c include file.h but does not use abc
File2.c includes file.h and uses abc
Is this a violation with respect to file1.c as it includes the header file but does not uses the macro.

The rules deals with unused tag and unused type declaration.

My query is whether the unused tag and unused types declared in "header" file are also violation of this rule. Example below to explain more:

content of test.h:

int16_t unusedtype (void)
{
typedef int16_t local_type;
return 67;
}

This header is included in test.c. Should the violations be reported on this.

In this case :

1. int *ptr ; // Is this compliant or non compliant
2. void foo()
3. {
4. /* Do Something. */
5. }

Global variables are initialized to 0 by default.
This means ptr is initialized to 0 automatically by compiler.

Ques : Is line 1 compliant or non compliant to Rule 11.9.

Does this rule also enforce initializing ptr to NULL for global pointers. ?

How should treat the combination of the tentative definitions?

What is the essential type of an enumerated constant? I believe it should be integer constant, and rule 10.3 seems to agree since it says this expression is compliant:

s8a = K1; /* constant value fits */

However, my static analyzer insists that this is a violation:

In the below case

#if 10
----
#elif 20
----
#endif

Since the part of the code
#elif 20
----
#endif

Is never gonna execute, is the rule applicable to this part of code i.e the part #elif 20 will be ignored while compilation so should the violation should be reported on it ?

Is it possible to declare bitfields that can be used as essentially boolean expressions in C90 without vialoating any MISRA rules?
Acording to section D.4, only a bit-field that has been implemented with an essential boolean type is essentially boolean. In C90, such a type does not exist as a "native" type. Sections 8.10.2 and D.6 allow an enumerated type as a way to define an essentially Boolean type. However, using such an enumerated type in a bitfield violates Rule 6.1.

Looking at the table for rule 10.1, the essential type of an enum and an unsigned integer differ, and rule 10.3 states that "The value of an expression shall not be assigned to an object with a
narrower essential type or of a different essential type category". I would think that means that you can not assign an enum to a signed or unsigned integer type, but the example section shows this as not violating the rule:

Rule 8.12 : Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique

The purpose of this rule is clearly to catch two enumerated constants that are *accidentally* assigned the same value. To this end, it makes sense to flag two constants with the same value, where one is auto assigned and one is manually assigned. However, I sometimes employ a paradigm that triggers a violation of this rule where I feel it is extremely clear that the duplicate assignment is not accidental, and so it would be nice to have an exception for this in future editions of the standard. It looks like this: