Welcome to the MISRA discussion forum

Rule 19.11
Double include protection. This rule is still OBL also for AC. May you provide some more detail on the rationale behind the necessity for this rules ?

best regards
Giacomo

Hello,

I've a doubt regarding the rule 043I of SLSF set. The rule tells: "In all flow-charts and graphical functions, exactly one unconditional transition must begin at every junction (except for the last junction). Every decision point (junction) must have a default path."
The problem is about the bounds of this rules, because it'd delimited only for flow-charts. Since a flowchart contains none or one state, the rule is not applied in case that I have a junction, without a default path, between two state.
Therefore my question is, why this rule (and as far as I know, no others) does not check default paths in junctions between states? Or else, why this rule is only flowcharts circumscribed and not statecharts as well?


Many thanks in advance,
any feedback will be really appreciated,

Alessandro

Hello,

I've a doubt regarding the rule 043I of SLSF set. The rule tells: "In all flow-charts and graphical functions, exactly one unconditional transition must begin at every junction (except for the last junction). Every decision point (junction) must have a default path."
The problem is about the bounds of this rules, because it'd delimited only for flow-charts. Since a flowchart contains none or one state, the rule is not applied in case that I have a junction, without a default path, between two state.
Therefore my question is, why this rule (and as far as I know, no others) does not check default paths in junctions between states? Or else, why this rule is only flowcharts circumscribed and not statecharts as well?


Many thanks in advance,
any feedback will be really appreciated,

Alessandro

Does this rule apply to objects which cannot be declared at block scope, like special function register variables?

Hi everyone!

I have a question about rule 10.1 and 10.2
Whenever I try to work with an if or while and use two comparions which are logically connected I get an MISRA issue when the two comparisons have different data types.
e.g. int16 and int32
Because the results of the two comparions is somehow boolean I would not expected to get:
The value of an expression implicitly converted to a different type.

Is it really an issue? I know I can cast both to the same data type but it looks strange.

Example:

Hello,

Is rule 7-5-3 really relevant?

It says that something like

Hi:

Does either ISO 26262 or MISRA SA documents provide any guidelines or requirements regarding use of "formal verification techniques" for ensuring correctness of safety-critical automotive SW? ANy benchmarks?

Can I get any references to significant works in applying formal verification techniques to auto-motive SW?

I'd appreciate if you can provide feedback.

Thanks and regards,

Srivas

Just to make sure, does rule 16.3 also apply to declarations of function pointers?

void (*pt2Function)(int);

Sould I give a name to the parameter?
Does that make sense at all?

The C standard states that "The typedef specifier is called a ‘‘storage-class specifier’’ for syntactic convenience only;".

Does 19.4 allow a macro to expand to 'typedef'?

The initialization:
uint8_t d = ((uint8_t) 0x1U) | ((uint8_t) 0x2U);
should, according to the MISRA-C guidelines, generate an error for rule 10.1. The initializer, i.e. the integer constant expression, has the underlying type of uint8_t, but that type is overruled by the explicit rule for integer constant expressions in 6.10.4 that says that the signedness/unsignedness of the underlying type should be taken from the actual type of the integer constant expression, but only if it is signed or unsigned int. In this case it is signed int. Giving the rule 10.1 breakage. Is this really the intention of the MISRA-C guidelines for integer constant expressions?