MISRA Discussion Forums

Welcome, Guest

You have to register before you can post on our site.

verify generated code with MISRA-C ?

Posted by: bmerkle - 21-07-2006, 05:41 AM - Forum: General Questions - Replies (2)

Hi there,

when using a UML modelling tool, should (according to MISRA) the generated code be verified, e.g. with MISRA-C ?

My experience is, that generated code often violates MISRA-C rules
and in IMO this is not a major issue, as you have to \"trust\" you codegenerator anyway ;-)

I think a better approach is, to verify the MODEL (and not the code) with some sort of model-checking...

Will the UML-group of MISRA produce such rules to verify against models ?

any other opinions, experiences ?

kind regards,
Bernhard.

Rule 5.6 / Rule 5.7

Posted by: sparker - 20-07-2006, 03:48 PM - Forum: 6.5 Identifiers - Replies (2)

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.)

Enumeration specifier

Posted by: fwamolina - 17-07-2006, 08:05 PM - Forum: 6.6 Types - Replies (3)

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

Code:
/* file.h */

typedef enum tagColor {

  Rojo,

  Azul,

  Verde,

  Negro,

  Blanco

} Colors_t;

/* file.c */

#include \"file.h\"

void main (void)

{

  U32          u32value01;

  U32          u32value02;

  U16          u16value;

  Colors_t     enumcolor;

  u32value01 = Rojo;

  u32value02 = Blanco + Negro;

  u16value = 2U;

  enumcolor = u16value;

}

Rule 8.11(req) - Clarification required

Posted by: Hammer - 10-07-2006, 12:46 PM - Forum: 6.8 Declarations and Definitions - Replies (1)

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.

Code:
int32_t var=0; /*VIOLATION, static should be applied*/

int32_t main(void)

{

var++;

return(var);

}

however I take a different meaning from the additional description given. I feel it is more related to the mixing use of extern and static.

Code:
extern int32_t var1;

static int32_t var1=0; /*Violation??*/

I would like to know which violation represents the meaning of this rule.

10.3. Casting to a narrower type

Posted by: Hammer - 06-07-2006, 01:30 PM - Forum: 6.10 Arithmetic Type Conversions - Replies (5)

Code:
(int16_t)(s32a * s32b) /*Compliant */

This example is found on page 45.

I would like clarification on how this can be compliant code without having to check whether the result of s32*s32 can fit into a short. is my understanding correct that the multiplication will take place as int32_t and then be casted to int16_t.

I would be grateful for some clarification on the topic.

MIRCA 2004 Rule 1.1

Posted by: vkmet - 04-07-2006, 08:23 AM - Forum: 6.1 Environment - Replies (1)

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

This cast is not defined for pointers

Posted by: warawut - 04-07-2006, 03:59 AM - Forum: General Questions - No Replies

	mda5tbl[] = { (u8)5, (u8)9, (void*)wsrid00 --> Warning No. 307 }; static void wsrid00(void) { u16 i; wmsgo[4] = 0; for(i=0; i

Rule 12.7 and underlying type

Posted by: aravind - 30-06-2006, 09:48 PM - Forum: 6.12 Expressions - Replies (1)

	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)

Rule 10.6: \"u\" Suffix to all unsigned constants

Posted by: Manni - 26-06-2006, 08:43 AM - Forum: 6.10 Arithmetic Type Conversions - Replies (5)

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 :

Code:
void foo(UINT b)

{

UINT a;

 a = b + 30;

}

I mean, it is not compliant . There must be \"u\"-Suffix:

Code:
void foo(UINT b)

{

UINT a;

 a = b + 30[b]u[/b];

}

1. reason:
\"Rule 10.6 (required): A \"U\" suffix shall be applied to all constants of unsigned type.\"

I think, it is a clear case, when I read this rule. There is spoken from \"all\" constants of unsigned Type. So why there should be no \"u\" Suffix?

2. reason:

In \"Rule 10.1 (required):\" in MISRA-C:2004, are examples for this:

MISRA-C:2004 in Rule 10.1/10.2

Code:
... u8a + 5 /* not compliant */

 ... u8a + 5U /* compliant */

For me it is really a clear case, there must be a \"u\" suffix at the constant. But we need to clarify it, with an official answer for this tiny problem.

Thanks

question to examples of rule 6.12.2

Posted by: Manni - 23-06-2006, 01:30 PM - Forum: 6.12 Expressions - Replies (2)

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++;

I don't understand, what could go wrong here:
1. x = y = y = z / 3 ;
2. x = y = y++;

If x = 1, y = 2, z = 3, I would say,

- for 1. the result for x is everytime 1
- for 2. the result for x is everytime 3

What could a compiler make different here?

thanks

Pages (100): « Previous 1 … 89 90 91 92 93 … 100 Next »

Search Forums

(Advanced Search)

Forum Statistics

» Members: 6,172
» Latest member: jeongsang kim
» Forum threads: 998
» Forum posts: 2,752

Full Statistics

Online Users

There are currently 227 online users.
» 0 Member(s) | 225 Guest(s)
Bing, Google

Latest Threads

Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: cgpzs
22-11-2024, 10:11 AM
» Replies: 0
» Views: 38

Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
21-11-2024, 01:12 PM
» Replies: 0
» Views: 51

A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 401

A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 339

model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,460

MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,876

MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,526

News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,708

Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,260

Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 452

Login
Username:
Password:
	Remember me Lost Password?

Welcome to the MISRA discussion forum