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

Username
  

Password
  





  Silencing the checker
Posted by: JonM - 08-02-2009, 08:35 AM - Forum: 6.2 Language Extensions - Replies (4)

What do people think of comments like these in code

/* defines to satisfy the MISRA checker tool */
... inevitable strange pre-processor magic


#if defined ( MISRA_CHECK )
.. behaviour 1
#endif

I see worrying amounts of it in a project I am working with and it makes me think I am working with unfinished code where the developers would rather continue writing insecure code by keeping a checker quiet than addressing the root causes. That this has been allowed by the checking tool vendor without

Does this kind of thing satisfy the spirit of MISRA and should checking tool vendors be inventing their own suppression language to litter the C-code with?

Does it break rule 2.4 - sections of code should not be commented out

Could we have a rule that bans checking tool logic, defines and comments in production code. Could we add a rule that requires checking tool vendors be required to discard the content of all well formed comments and not add mechansims for the programmer to determine if a checking tool is parsing the code? please.

Jonathan

Print this item

  Rule 12.2: Accessing volatiles in simple assignment statemnt
Posted by: joa07 - 30-01-2009, 09:44 AM - Forum: 6.12 Expressions - Replies (7)

Hi!

It is stated in the MISRA-C:2004 rule 12.2 (required) that "...it is recommended that volatiles only be accessed in simple assignment statements, such as the following:"

Code:
volatile uint16_t v;
/* ... */
x = v;
Is this recommendation a part of the MISRA-C:2004 12.2 rule, or is it just a common recommendation?
Should a MISRA-C:2004 analysis tool try to enforce this kind of assignment statement?

Is the following statement part of the "simple assignment statements" philosophy (I think so)?
Code:
volatile uint32_t *v = AN_ADDRESS;
/* ... */
*v = x;

The reason for this question is that our current analysis tool raises a MISRA-C:12.2 violation for the last code snippet above, and I think this is a misinterpretation of the guidelines.

//JOA

Print this item

  Clarification for 6-5-1
Posted by: pkruk - 12-01-2009, 10:21 AM - Forum: 6.5 Expressions (C++) - Replies (1)

Quote:A for loop shall contain a single loop-counter which shall not have floating type.

Is following code compliant?

Code:
void foo() {
    const char * x = "Foo";
    for (const char * ptr = x; *ptr; ++ptr) { // Compliant?
        // ...
    }
}

In my opinion the loop-control-variable (ptr) is not "an operand to a relational operator in condition" (the variable pointed to by the ptr is the operand) so it does not meet conditions for a loop-counter.

Print this item

  Clarification for 7–5–1
Posted by: pkruk - 12-01-2009, 09:48 AM - Forum: 6.7 Declarations (C++) - Replies (1)

Quote:A function shall not return a reference or a pointer to an automatic variable (including parameters), defined within the function.

I have a question about reference types. Is the following code compliant or not?


Code:
int global_var;

int & foo(int & ref) {
    return ref;             // Compliant?
    
    int & global_ref = global_var;
    return global_ref;      // Compliant?
    
    int local_var;
    int & local_ref = local_var;
    return local_ref;       // Compliant?
}

int * bar(int & ref) {
    return &ref;            // Compliant?

    int & global_ref = global_var;
    return &global_ref;     // Compliant?
    
    int local_var;
    int & local_ref = local_var;
    return &local_ref;      // Compliant?
}

Print this item

  Realizing f strong typing
Posted by: B3NN7 - 10-01-2009, 02:48 PM - Forum: General Questions - Replies (1)

Hello,

I have a problem by realizing a strong typed library function. The library function shall get a pointer to one byte and the number of bytes up on the pointer to be read.

But I does have the requirement that only local variables on the stack or global variables at the data area of the C Application may be processed by my function.

Here is a bad example:

Code:
void function(const void* const Data_pv, const uint8_t Size_u8)
{
   ...
}

void* Address = 0xFFAF;

function(Address, 8);

It shall not be possible to pass a pointer on void.

Here is a good example

Code:
uint32_t Data_u32 = 5;

function( (uint8_t*)&Data_32, sizeof(Data_u32));

Is there a rule of MISRA C supporting me by realizing my described problem ?

Thanks B3NNY

Print this item

  Example for Rule 12–1–1
Posted by: pkruk - 24-12-2008, 11:34 AM - Forum: 6.12 Special member functions (C++) - Replies (1)

Hello,

I'm not sure if the example for this rule is correct in one case. Simplified code:

Code:
class B2
{
public:
virtual ~B2 ( );
B2 ( )
{
typeid ( B2 ); // Non-compliant
}
};

Why is this typeid non compliant? It does not use object’s dynamic type so it should not be a violation of the rule. This is similar to using typeid on e.g. not polymorphic type, which is allowed by the rule. ISO/IEC 14882:2003(E) standard:

Quote:5.2.8
3. When typeid is applied to an expression other than an lvalue of a polymorphic class type, the result
refers to a type_info object representing the static type of the expression. [...]
4. When typeid is applied to a type-id, the result refers to a type_info object representing the type of the
type-id. [...]

Print this item

  Rule 8.10 and init functions
Posted by: Christoph - 28-11-2008, 09:41 AM - Forum: 6.8 Declarations and Definitions - Replies (2)

Hi,

usualy when a C module is designed (at our company), it consists of at least one external function. An example:

module.h:
extern void initModule()
extern void setData(uint8_t data)
extern uint8_t getData()

now initModule() is called in main (once in the whole software), as it is an init function. From a design point of
view module.* is the right place for initModule(), but Misra suggests to define it in main, since it is only called there.
I think this is bad design and not always possible (e.g. because module variables are hidden and not accessible form main).

So what is your recommendation in such a case? Is there a best practice for this pattern?

Best Regards
Christoph

Print this item

  Rule 18-4-1 (ban of dynamic heap memory allocation)
Posted by: shanz - 29-09-2008, 09:28 AM - Forum: 6.18 Language support library (C++) - Replies (1)

One of the most commonly quoted advantages of object orientation is polymorphism.
C++ often relies on dynamically allocated pointers to achieve (run-time) polymorphism.

How can polymorphism be achieved without resorting to dynamic memory allocation?
I suspect that preallocating pointers on the stack is the answer but can someone please write some example code?

Thanks.

Print this item

  Incorrect comment in mc2_1703.c
Posted by: Graham Andrews - 17-09-2008, 01:27 PM - Forum: MISRA-C:2004 Exemplar Suite - Replies (1)

There is a comment regarding line:

Code:
else if ( ( &array_12 [ 12 ] - &array_12 [ index_1 ] ) > 0 )
The comment states that this line violates rule 17.4, which is not the case, as the variable array_12 has been declared as an array.
It should state that there is a violation of rule 21.1 regarding array bound errors.

Print this item

  Can I get by with a little help from My Friends?
Posted by: gs - 12-09-2008, 06:50 PM - Forum: 6.11 Member access control (C++) - Replies (1)

Rule 11-0-1 states,

Quote:Member data in non-POD class types shall be private.
with the rationale:
Quote:By implementing class interfaces with member functions, the implementation retains more control over how the object state can be modified, and helps to allow a class to be maintained without affecting clients.
Does the above mean non-POD structure types should not contain any friend declarations? A friend declaration would by definition allow for the circumvention of the access restrictions.

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,213
» Latest member: RichardEdward
» Forum threads: 1,017
» Forum posts: 2,796

Full Statistics

Online Users
There are currently 146 online users.
» 0 Member(s) | 143 Guest(s)
Bing, Google, UptimeRobot

Latest Threads
Rule 7.0.5, example non-c...
Forum: 4.7 Standard conversions
Last Post: cgpzs
17-04-2025, 12:10 PM
» Replies: 0
» Views: 186
A3-3-2 Contradictory exam...
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
31-03-2025, 09:30 AM
» Replies: 2
» Views: 322
16.6.1 clarification
Forum: 4.16 Overloading
Last Post: cgpzs
31-03-2025, 09:29 AM
» Replies: 2
» Views: 303
Rule 9.3.1 - iteration st...
Forum: 4.9 Statements
Last Post: misra cpp
28-03-2025, 01:17 PM
» Replies: 1
» Views: 196
Rule 8.2.8 - why aren't a...
Forum: 4.8 Expressions
Last Post: misra cpp
28-03-2025, 01:05 PM
» Replies: 1
» Views: 218
Typo in Appendix C of MIS...
Forum: 8.10 The essential type model
Last Post: Yordan Naydenov
17-03-2025, 02:58 PM
» Replies: 0
» Views: 183
Adopted modal expressions...
Forum: General Questions
Last Post: Yordan Naydenov
17-03-2025, 09:01 AM
» Replies: 0
» Views: 287
Roadmap to c23 support
Forum: General Questions
Last Post: ACHart
28-02-2025, 03:23 PM
» Replies: 0
» Views: 222
Rule 6.2.1 weak linkage
Forum: 4.6 Basic concepts
Last Post: misra cpp
28-02-2025, 01:04 PM
» Replies: 1
» Views: 281
A8-4-5: Should have an ex...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
21-02-2025, 12:58 PM
» Replies: 3
» Views: 726