Welcome to the MISRA discussion forum

I'm confused by the difference between the two examples in these two rules. In R5.6 we're shown that it is ok to reuse the structure member identifier \"next\" since \"member names are less likely to be confused\", and in R5.7 we're shown that members of two different structure types cannot have the same name (\"speed\").

Is the intention that one deviates from R5.7 leaving R5.6 to catch the most important cases? If so that isn't very clear from the text.

(Overall I'd be surprised if anyone ever sticks to R5.7 since it means that every identifier in your program, even every local, has to differ from every other. That means no \"i\", \"j\", \"p\", \"speed\", \"rpm\", ..., \"index\", etc.)

My question is if there are one or more errors in this code?????????

Dear Misra

I seek clarification on the particular meaning of this rule. From the rule statment I take it that everything declared at file scope and only used internally should have the static storage class specifier applied.

For example the following would be a violation, ignoring the violation of rule 8.7.

Hi,

MISRAC 2004 Rule 1.1 refers to the environment limits specified in section 5.2.4 of the ISO 9899:1990 standard.

According to this rule, should all the limits specified by this section be STRICTLY followed, or only the one limit on internal and extrenal identifier length be strictly followed (Rule 5.1). Is a piece of code having 128 nesting levels of blocks MISRAC compliant?

Also there is a mention of the need to have certain compiler extentions in the code. Is a piece of code, having certain compiler extentions MISRA compliant? Or is it upto the organisation to decide that?

Best Regards
Vkmet

mda5tbl[] = { (u8)5,
(u8)9,
(void*)wsrid00 --> Warning No. 307 };

static void wsrid00(void)
{
u16 i;
wmsgo[4] = 0;
for(i=0; i

Hi,

Question on 12.7: Bitwise operators shall not be applied to operands whose underlying type is signed

[code]int32_T var1[32];
uint16_T var2 = 5U;
int32_T var3 = var1[(var2 - 1)

Hello

I have a disagreement with a supporter of a bigger MISRA-C:2004 rule checking tool.

He means, that the following is MISRA-C:2004 compliant :

Hi

In Rule 12.2

Quote:nested assignment statements
Assignments nested within expressions cause additional side effects. The best way to avoid any chance of this leading to a dependence on order of evaluation is to not embed assignments within expressions.

For example, the following is not recommended:
x = y = y = z / 3 ;
x = y = y++;

My question is if the code bellow is not compliance with misrac-2004

uint16_t GetSpeed (void);
void IncreaseSpeed (void);
void DecreaseSpeed (void);
void GoodSpeed (void);

enum tagSPEED
{
Low,
Medium,
High
};

void main (void)
{
uint16_t uSpeed;

uSpeed = GetSpeed();

switch (uSpeed)
{
case Low:
IncreaseSpeed();
break;

case Medium:
GoodSpeed (void);
break;

case High:
DecreaseSpeed (void);
break;

default:
break;
}
}

Is there any solution for this case?


Normative reference:
Ansi-Iso-9899-1990 (6.5.2.2)
Misra-c2004 (6.10.3)