MISRA Discussion Forums
Portal

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

Username
  

Password
  

  Rule #5.1 clarification
Posted by: gs - 10-12-2012, 03:49 PM - Forum: 6.5 Identifiers - Replies (1)

Hi,
The conversation at http://www.misra.org.uk/forum/viewtopic.php?f=61&t=508 states identifiers longer than 31 characters are permitted. However, the exemplar suite suggest such identifiers are, per se, prohibited. Which is correct?

Print this item

  10.1 Non-constant value to function
Posted by: borth - 26-11-2012, 11:58 AM - Forum: 6.10 Arithmetic Type Conversions - Replies (1)

Hey,

i have a problem with these 10.1 Rule:

Code:
void foo_bar(uint32_t u32)      /* another function to do something */

void test_func(uint8_t u8)
{
   uint32_t u32Convert = (uint32_t)u8;
   ...
   foo_bar(u32Convert);      /*Error - Note 960 Violates MISRA 2004 Required Rule 10.1, Prohibited Implicit Conversion: Non-constant argument to function */
   ...
}
MISRA says that a expression, which is a function argument, shouldn't be converted to a underlying type.
But i took a 8 bit value, expand to 32bit and use this for the function. The type of u32Convert is uint32_t as it should be for the function argument of foo_bar.
Is it neccessary to know what foo_bar does with the value?

Thanks for your help!
Greetz,

Print this item

  MISRA C Exemplar suite : Compilation errors
Posted by: tarun.g - 24-10-2012, 07:35 AM - Forum: MISRA-C:2004 Exemplar Suite - Replies (1)

I encountered a few cases in the exemplar suite(the list mentioned below) where in any standard compiler throws an error.
1. mc2_1101.c
2. mc2_1102.c
3. mc2_1903.c
4. mc2_1908.c
5. mc2_1914.c
6. mc2_1917.c

Are all the cases(but the ones which explicitly mention that the compiler is to fail) in the exemplar suite, in general, expected to
be successfully compiled by a "MISRA standard complaint" compiler?

Print this item

  Is 16.4 violated if 16.3 is?
Posted by: gs - 11-10-2012, 08:23 PM - Forum: 6.16 Functions - Replies (1)

Given the following code:

Code:
void f(int);
void f(int x){}
Does this code violate rule #16.4, identifiers used in the declaration and definition of a function shall be identical? While the lack of a parameter name in the prototype violates #16.3, I am not sure if violating #16.4 is possible in that case.

Print this item

  10.1 in a macro
Posted by: borth - 02-10-2012, 06:34 AM - Forum: 6.10 Arithmetic Type Conversions - Replies (2)

Hello,


i got something like this:

[code]
#define X_MASK 0xFU
#define FOO(_a) ((_a) % 10U)
#define BAR(_b) (1U

Print this item

  0-1-8 and OO design pattern
Posted by: masha - 02-10-2012, 06:03 AM - Forum: 6.0 Language independent issues (C++) - Replies (1)

0-1-8 restricts such elegant design pattern as e. g. observer/listener (with selective handling of a subset of notifications by observer).
So is the "intended" use of empty virtual methods due to design OK? May design goals be classified as "side effect"?

Print this item

  15.2 and 'break's inside if-else
Posted by: gs - 06-09-2012, 07:26 PM - Forum: 6.15 Switch Statements - Replies (4)

Suppose I have the following code:

Code:
...
switch( x )
{
case 1:
    if( y )
        {
        ...
        break;
        }
    else
        {
        ...
        break;
        }
default:
    break;
}
...

Does this code violate rule #15.2?

Print this item

  Rule 19.3 - #include... - what about directories?
Posted by: SafeT - 20-07-2012, 04:53 PM - Forum: 6.19 Preprocessing Directives - Replies (1)

Hi,

Question about rule 19.3 -

I read this rule as forbidding constructs such as:

Code:
#include "foo/bar/baz.c"
and especially things like
Code:
#include "/usr/local/include/baz.h"
#include "C:/Windows/blah/baz.h"

because there is directory information following the #include keyword (it's not just a filename).

It's not clear to me whether or not the above example would violate rule 19.3 - can you please weigh in?

I think the use of absolute *or* relative directories on a #include line is a maintenance nightmare and can lead to unintended (read: incorrect) header files being included, especially as code is refactored and as source files are moved around.

My opinion (and my experience in safety-critical systems) is that #include directives should only specify a filename, not a path of any kind, and the build configuration should specify the appropriate directories to search, and in what order.

Can you please comment?

(David (or anyone from MISRA)) - I have some comments (such as this one) regarding the review draft copy of MISRA-C3, but I missed the deadline of May 31 for submitting comments. Is it too late? You can contact me through the email on my account or PM if that is better, thanks!)

Print this item

  Unreachable break in a case statement
Posted by: danielb - 04-07-2012, 08:14 AM - Forum: 6.15 Switch Statements - Replies (1)

I have recently come across two different rule interpretations of the following code:

Code:
switch(cond)
{
  case 0:
  {
    /* A deliberate infinite loop. */
    for ( ; ; ) { }
    
    /* Unreachable break statement. */
    break;
  }
  [ … ]
}
One MISRA checker insists on the break statement referring to rule 15.2, while the other insists that the break statement is unreachable code according to rule 14.1.

Both rules are required, however, both can not be enforced in this case. Which rule supersedes the other?

Print this item

  3-9-2 and 'bool'
Posted by: gs - 12-06-2012, 02:23 PM - Forum: 6.3 Basic concepts (C++) - Replies (4)

Is rule #3-9-2 intended to apply to the 'bool' type?

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,171
» Latest member: stephanmuench
» Forum threads: 998
» Forum posts: 2,752

Full Statistics

Online Users
There are currently 330 online users.
» 0 Member(s) | 329 Guest(s)
Bing

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: 31
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
21-11-2024, 01:12 PM
» Replies: 0
» Views: 37
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 383
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 329
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,447
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,863
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,510
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,695
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,250
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 439