MISRA Discussion Forums

Welcome, Guest

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

Rule 0-1-11 and postfix increment/decrement operators

Posted by: rrosier - 19-11-2020, 04:29 PM - Forum: 6.0 Language independent issues (C++) - Replies (2)

Rule 0-1-11 states that there shall be no unused parameters (named or unnamed) in a non-virtual function.

However, when writing a postfix increment/decrement operator, the C++ standard states:

Quote:If the function is a member function with one parameter (which shall be of type int) or a non-member function with two parameters (the second of which shall be of type int), it defines the postfix increment operator ++ for objects of that type.
...
The prefix and postfix decrement operators -- are handled analogously.

Such operators are then written as:

Code:
struct X {

  X operator++(int); // postfix a++

};

On the face of it, this seems to violate Rule 0-1-11, because the unnamed int parameter is unused.

Is this an real violation, so that in order to write postfix increment/decrement operators we have to deviate, or is this rule not intended to apply in such cases where the C++ standard itself is defining that the parameter is unused (and therefore any flagging of such code is a false positive)?

I cannot find any direct prohibition of the writing of postfix increment/decrement operators elsewhere in the MISRA rules, so it surprises me that this rule appears to prohibit their use in this roundabout fashion.

Rule 0-1-6 and Boolean variables

Posted by: LordMordac - 18-11-2020, 09:50 PM - Forum: 6.0 Language independent issues (C++) - Replies (13)

Rule 0-1-6 seems to be counter productive with Boolean variables. DU dataflow anomalies are normal and desirable with Boolean variables. For example:

Code:
extern bool random_bool ();

bool non_compliant_and (void)

{

    bool const b1 = random_bool();

    bool const b2 = random_bool();

    return b1 && b2;   // b2 is DU dataflow anomaly when b1 is false

}

bool non_compliant_or (void)

{

    bool const b1 = random_bool();

    bool const b2 = random_bool();

    return b1 || b2;   // b2 is DU dataflow anomaly when b1 is true

}

bool compliant_and (void)

{

    bool const b1 = random_bool();

    bool const b2 = random_bool();

    bool tmp = b1;

    tmp = b2 && b1;

    return tmp;

}

bool compliant_or (void)

{

    bool const b1 = random_bool();

    bool const b2 = random_bool();

    bool tmp = b1;

    tmp = b2 || b1;

    return tmp;

}

The compliant and non-compliant code result in different binaries. Both seem equally safe, but the compliant solution is less efficient. Which seems at odds with the statement in MISRA spec claims

Quote:At best this (DU dataflow anomaly) is inefficient, but may indicate a genuine problem.

Is there any insight anyone can provide on such a perplexing problem?

Misra Rules for cppcheck

Posted by: julred - 04-11-2020, 05:58 AM - Forum: General Questions - Replies (6)

	Hi everyone, I'm using the application cppcheck for my existing development. Now I'd like to add the functionality of checking my sources against Misra rules. Therefor I need the Misra Rules in a .txt file format. Where can I get it? BR

Rule 21.8, assert, and abort

Posted by: michael.metivier - 02-11-2020, 10:21 PM - Forum: 8.21 Standard libraries - Replies (1)

	Does the prohibition on calling the termination functions, specifically "abort", given by Rule 21.8 apply for any process that may arrive at abort? Or only to direct calls to abort requested by user-written code? This is of interest due to the definition of assert which indicates that it calls the "abort" function if the assert fails. Does 21.8, then, prohibit the use of assert?

Rule 3-2-1 and compatible types

Posted by: getMW - 18-09-2020, 08:47 AM - Forum: 6.3 Basic concepts (C++) - Replies (3)

the rule says "All declarations of an object or function shall have compatible types."

the question is: how do you define "compatible types"?

-if we think it is similar to MISRA-C:2004 8.4 "If objects or functions are declared more than once their types shall be compatible."
or to MISRA-C:2012 8.3 that says "Compatible versions of the same basic type may be used interchangeably. For example, int, signed and signed int are all equivalent."
=> then we can look at the definition of compatible types defined in C norm (sections 6.1.2.6, 6.5.2, 6.5.3 and 6.5.4 for C90)

-but C++ norm does not define those compatible types and even more, it says in the Annex C.1 3.9(5)

Quote:Change: C allows “compatible types” in several places, C++ does not

so what are compatible types in C++? do you use C compatible types even if C++ norm rejects them?
do you use another definition?

Practical example: on the example given in MISRA-C++ documentation

Code:
// File a.cpp

extern int32_t a;

// File b.cpp

extern int64_t a;   // Non-compliant – not compatible

-do you expect that it is always non compliant, whatever the platform is? (whatever are the size of int32_t and int64_t)
-or can we consider that

it can be compliant on platform where int32_t and int64_t have same signess and size

it can be non-compliant on platforms where size are different

Is it possible to define your own Boolean types?

Posted by: andrea96b1 - 06-07-2020, 07:44 AM - Forum: 8.10 The essential type model - Replies (1)

Hello,

I want to know if it is possible to define a Boolean type and do not use the one defined in the stdbool.h. Can I define Boolean like this:

Code:
typedef uint8_t boolean;

and

Code:
#define TRUE 0x1

and

Code:
#define FALSE 0x0

? And If I define Boolean in this way, what operations, which if done using standard booleans would I violate?

Sorry in advance If the question is not too clear and If I made some mistake.

Rule 5.7 - Uniqueness of Tags as Identifiers

Posted by: j-nafziger - 01-07-2020, 03:13 PM - Forum: 8.5 Identifers - Replies (1)

Hi -

The amplification in Rule 5.7 says that a tag shall be unique across all name spaces and translation units.

Should this be read such that:
- A tag shall be unique across (all tags in) all name spaces and translation units.
- A tag shall be unique across (all identifiers in) all name spaces and translation units.

The distinction I am drawing being could a unique identifier of a tag be reused for other non-tag identifiers?

The examples in Rule 5.7 only show conflicts between tags and do not show conflicts between tags and other kinds of identifiers (labels, members, ordinary identifiers).

For example is this code violating Rule 5.7 (reuse of 'device' as a member and a tag)?

Code:
struct clock {

    u32     device;  /* Device is a 'member' */

} ;

struct device;  /* device is a tag */

Thanks!

Rule 22.1: object declaration and deleted timing

Posted by: andy_su - 04-05-2020, 01:10 AM - Forum: 8.22 Resources - Replies (1)

Hi, I have a question about object declaration and deleted timing.
I need to declare an object in constructor and release it in deconstructor, because the object will be reused frequently, but it is not compliant on MISRA C 2012.
The sample code as below.
Could you give me any hint to solve it?
Thanks.

Code:
ABC::aa(const Arguments& args)

{ 

    pImpl = new ABC::impl(args); 

}

ABC::~aa() 

{ 

    delete pImpl; 

    pImpl = NULL;

}

Essential type of ~(uint16_t)0x30

Posted by: grunwald - 09-04-2020, 04:37 PM - Forum: 8.10 The essential type model - Replies (1)

What is the essential type of "~(uint16_t)0x30" ?

Going by Appendix D "Bitwise complement":
* The operand is essentially unsigned
* The operand is an integer constant expression
* The result of "~(uint16_t)0x30" is -49 of standard type int (assuming int is 32 bits and twos complement).
* The UTLR of -49 is ill-defined.

Option 1: If the resulting constant is negative, convert it to the unsigned type corresponding to the expression's standard type, then use the UTLR of that converted value. This would result in "~(uint16_t)0x30" having essential type "unsigned int" (same as without the cast to uint16_t).

Option 2: If the resulting constant is negative, treat the expression as if it was non-constant, using the essential type of the operand instead. This would result in "~(uint16_t)0x30" having essential type "uint16_t" (same as if 0x30 wasn't a compile-time constant).

Option 3: If the resulting constant is negative, use the standard type for the essential type. This would result in "~(uint16_t)0x30" having essential type "signed int".

This also affects other constant expressions producing negative values after integral promotion, e.g. "(uint16_t)300u - (uint16_t)301u".

MISRAC2012-Rule-16.1 : The body of this switch statement is not well-formed

Posted by: jsleeman - 26-03-2020, 10:53 AM - Forum: 8.16 Switch statements - Replies (1)

Hello everyone,

I have 2 functions below, the top one, I get a MISRAC2012-Rule-16.1 warning, the second one I do not get the warning, the only difference between them is where 'i' is declared.
Is the warning I am seeing correct? If it is why is it not allowed?
I have looked through the 16.x rules and I could not see anything that suggested I could it was banned.
I am using IAR C-STAT to do the analysis.

Code:
/***************

 * I get the following warning on this switch statement: MISRAC2012-Rule-16.1 : The body of this switch statement is not well-formed.

 ***************/

uint32_t func(uint32_t num)

{

   uint32_t result;

   switch(num)

   {

      case 0:

      {

         result = 123U;

         break;

      }

      case 1:

      {

         result = 567U;

         for (uint32_t i = 0U; i < 10U; i++)

         {

            result = i + result;

         }

         break;

      }

      default:

      {

         result = 0;

         break;

      }

   }

   return result;

}

uint32_t func_b(uint32_t num)

{

   uint32_t result;

   switch(num)

   {

      case 0:

      {

         result = 123U;

         break;

      }

      case 1:

      {

         uint32_t i;

         result = 567U;

         /***************

          * If I declare 'i' outside of the loop this warning goes away: MISRAC2012-Rule-16.1 : The body of this switch statement is not well-formed.

          ***************/

         for (i = 0U; i < 10U; i++)

         {

            result = i + result;

         }

         break;

      }

      default:

      {

         result = 0;

         break;

      }

   }

   return result;

}

Thanks,
James

Pages (100): « Previous 1 … 13 14 15 16 17 … 100 Next »

Search Forums

(Advanced Search)

Forum Statistics

» Members: 6,171
» Latest member: stephanmuench
» Forum threads: 997
» Forum posts: 2,751

Full Statistics

Online Users

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

Latest Threads

Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
Yesterday, 01:12 PM
» Replies: 0
» Views: 28

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

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

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

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

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

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

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

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

MISRA 2023 Test Suite
Forum: General Questions
Last Post: grigdon
14-10-2024, 01:27 PM
» Replies: 0
» Views: 184

Login
Username:
Password:
	Remember me Lost Password?

Welcome to the MISRA discussion forum