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

Username
  

Password
  





  Rule 12.6, effectively Boolean expressions in assignment?
Posted by: rmgalles - 03-02-2006, 09:29 PM - Forum: 6.12 Expressions - Replies (1)

The second sentence in Rule 12.6 says \"Expressions that are effectively Boolean should not be used as operands to operators other than (&&, || and !).\"

This makes sense for most operators, but what about the simple assignment operator?

Code:
bool a;

a = (b == c); /* is this allowed? */

Perhaps a disclaimer \"other than assignment\" could be added?

Print this item

  Rule 19.16
Posted by: nikunj - 02-02-2006, 09:04 AM - Forum: 6.19 Preprocessing Directives - Replies (2)

The syntax errors the rule talks about would any way be reflected as an sytax error by the compiler.

for example in
#defineNAME \"test\"

the complier would return an error.

So in effect the rule becomes redundant!

Print this item

  Rule 11.1 Interpretation
Posted by: nikunj - 02-02-2006, 08:59 AM - Forum: 6.11 Pointer Type Conversions - Replies (1)

Rule 11.1 says that, 'coversions shall not be performed between a pointer to a function and any other type other than an integral type'

what do the 'integral type' refer to?

Is there a violation in the following code:

int (*p)();
int *a;
p = a; /* is this a violation of Misra rule 11.1 ? */

Print this item

  Does 13.7 apply to ALL invariant Boolean expressions?
Posted by: rmgalles - 31-01-2006, 10:12 PM - Forum: 6.13 Control Statement Expressions - Replies (1)

The example only shows relational operators { < >= }.

What about other operators?
#define OPTION_ONE 0x01
#define OPTION_TWO 0x02

#define MY_OPTIONS (OPTION_ONE)
- or -
#define MY_OPTIONS (OPTION_TWO)
- or -
#define MY_OPTIONS (0x00)
- or -
#define MY_OPTIONS (OPTION_ONE | OPTION_TWO)


if ((MY_OPTIONS & OPTION_ONE) != 0) /* deviation from 13.7? */
{
...
}


In this case, equality operators { == != } are less likely to \"accidentally\" be always true/false (vs. intentionally always true/false), while relational operators can sometimes catch the programmer of guard (due to limited ranges of smaller integer types: [-128 to +127], [0 to +255], etc.


What about sub-expressions?
if ((u8

Print this item

  What operators are prohibited/allowed by rule 12.13?
Posted by: rmgalles - 31-01-2006, 08:37 PM - Forum: 6.12 Expressions - Replies (2)

The requirement text of rule 12.13 simply states ++ and -- \"should not be mixed with other operators in an expression\", but it doesn't qualify which operators. In the supporting text, the general \"operators\" term is qualified with \"in combination with other arithmetic operators\" but doesn't specify what the \"arithmetic operators\" are.

The simple example only seems to prohibit addition { + }, which would naturally extend to { + - * / % }, and it would be reasonable to include bitwise operators { ~ & ^ | > }.

I just want to understand how restrictive this rule is.

At a minimum, you would need to permit address and indirection operators as well as structure and union member operators:
{ * & [] . -> }, where * is the unary indirection operator (not multiply), and & is the unary address operator (not bitwise AND operator).

It would also be reasonable to use relational operators { < >= }
as well as equality operators { == != }.

However, is the simple assignment operator { = } allowed?

What about compound assignment operators?
{ += -= *= /= %= &= ^= |= = }

Which of the following examples are permitted under rule 12.13?
(1) (*p)++;
(2) a[i]++;
(3) my_struct.member++;
(4) my_struct_ptr->member++;

(5) a = b++;
(6) pop_value = buffer[--index];
(7) buffer[index++] = push_value;
(8) *p1++ = *p2++;

(9) do { ... } while ((i--) > 0);

(10) sum += buffer[i++];

My thoughts:
(1) to (4) DEFINITELY allowed (just using operators to reference correct object in memory to increment/decrement).

(5) to (8) SHOULD be allowed: common to use ++ -- in \"simple\" assignments to copy data between objects.

(9) COULD be allowed: while() or do-while() loops may sometimes be preferred over for() loops.

(10) likely NOT allowed, as:
E1 = E2
is just shorthand syntax for:
E1 = E1 (E2)
for all the compound assignment operators.

So, any code using any of these (binary) operators would be discouraged:
{ + - * / % & ^ | > }

What about unary operators:
{ + - ~ }

Just for reference, QAC (6.0.1) with MISRA-C:2004 compliance module M2CM (v1.1) interprets rule 12.13 as a violation with the QAC rule:
3440 Result of ++ or -- operator used in expression.

Thus, it only allows (1) to (4), and prohibits the other forms.
Is QAC's interpretation correct? Or, are more variations allowed?

My concern is an interpretation that is too restrictive will encourage users to always take exception to the rule (i.e., disable the static analysis rule check), rather than having a rule that pinpoints examples that would likely result in a software defect (which would discourage disabling the rule).

This could be split into two rules, one that prohibits ++ and -- used with any of the following operators:
{ + - * / % ~ & ^ | > }

And another that prohibits using the result of ++ or -- operator in an expression.

This provides a two-stage filter, one that catches the more \"serious\" issue, and a more conservative filter that prohibits rather benign code.

Print this item

  static function prototype
Posted by: bpereira - 11-01-2006, 09:32 AM - Forum: 6.8 Declarations and Definitions - Replies (2)

The specification isn't clear about static function, should they have prototype or not ?

The rule talk about declaration in header file, of course this isn't applicable to static function. So it sound to me that static function should not have prototype.

Print this item

  Misra rule 45
Posted by: meens_india - 05-01-2006, 08:43 AM - Forum: 6.11 Pointer Type Conversions - Replies (5)

Hi,

i compiled the following code using a misra checking compiler

unsigned char data[1];
memset(&data,0x00,sizeof(data));

after compilation it was showing two errors violating rule 45 and rule 77


i changed the line as given below.
memset((void*)&data,0x00,sizeof(data));

it removed the error violating 77.

But i couldnot find any way to comply with rule 45

Can any one have any idea to perform the above actions without
violating the rule

Print this item

  Compiler
Posted by: qspi - 16-12-2005, 01:59 PM - Forum: General Questions - Replies (5)

I've got a project running under Safety Integrity Level 3 (MISRA).
I do have a static checker tool to enforce the rules put forth by the MISRA-C:2004, but I still do have to validate my compiler against MISRA, don't I?

What is the meaning of the following sentences found in the document?

\"The validation test [...] for compilers could consist of known good code from previous application. [...] It should be noted that validation testing of the compiler must be performed for the same set of compiler options, linker options and source library versions used when compiling the product code.\"
\"When choosing a compiler (which should be understood to include the linker), an ISO C compliant compiler should be used whenever possible. Where the use of the language is reliant on an \"implementation-defined\" feature (as identified in Annex G.3 of the ISO standard) then the developer must benchmark the compiler to establish that the implementation is as documented by the compiler writer.\"

And furthermore the next two rules: 6.1.1, 6.1.2

So if you know how to validate the compilation process of a compiler, or you know any compiler that is said to be MISRA compliant, please send response.

Print this item

  conversions with constant
Posted by: natapush - 17-11-2005, 02:05 PM - Forum: 6.10 Arithmetic Type Conversions - Replies (1)

why are the following expressions are compliant/not compliant

u8a = 5U - compliant(u8a=u16b - not compliant at the same time)
u8a = 5UL not compliant

it is not a conversion to a wider integer type of the same signedness as in 10.1 a)
It is more an implicit conversion from wider to narrower types.
And why in one case it is compliant, and in another one not compliant.

Print this item

  16-bit and 32-bit compatibility
Posted by: natapush - 17-11-2005, 02:01 PM - Forum: 6.10 Arithmetic Type Conversions - Replies (1)

1.The expression

u16a = u16b + u16c yields a u16 bit result if int is 16 bits, this means that
u16a = u16b + u16c is compliant on a 16-bit machine.

but
u16a = u16b + u16c yields a signed 32 bit result on a 32-bit machine, so explicit type case has to be used to make the result compliant?
u16a =(u16)(u16b + u16c )

but this is not MISRA comform(rule 10.3 says type has to be narrower as the underlying type)

what is the solution for the expression u16a = u16b + u16c to be MISRA -conform on both machines?(will u16a = (u16)u16b + (u16)u16c also result in integral promotion?)

2. int16_t foo1(uint8_t x)
{
return(20000) compliant on the 16 bit machine
return(20000) not compliant on the 32 bit machine
}

right? (this is from example to rules 10.1-10.2 return(20000))

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,173
» Latest member: SnakeLeon
» Forum threads: 998
» Forum posts: 2,752

Full Statistics

Online Users
There are currently 557 online users.
» 0 Member(s) | 554 Guest(s)
Applebot, 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: 43
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
21-11-2024, 01:12 PM
» Replies: 0
» Views: 55
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 406
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 343
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,463
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,878
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,535
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,709
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,265
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 458