MISRA Discussion Forums
Portal

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

Username
  

Password
  

  A signed bit field of 1 bit length is not useful
Posted by: JonM - 08-02-2009, 08:41 AM - Forum: 6.5 Identifiers - Replies (2)

Is it possible to improve Rule 6.5 "A signed bit field of 1 bit length is not useful". Unlike the other rules, this doesn't actually advise/recommend any behaviour or give any insight as to what compilers may or may not do when presented with this.

How about - following the same outline structure of the following rule 7.1, something like:

A signed bit field of 1 bit length is treated as ...

There is a danger of ...

They are problematic when ...

It is better not to use signed bit fields of 1 bit length use ...

Jonathan

Print this item

  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

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 264 online users.
» 0 Member(s) | 261 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: 36
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
21-11-2024, 01:12 PM
» Replies: 0
» Views: 44
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 399
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,459
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,875
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,523
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,707
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,258
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 449