MISRA Discussion Forums

Welcome, Guest

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

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

Rule 2.5 and unused macro parameter

Posted by: Mike Bailey - 12-03-2020, 03:04 PM - Forum: 8.2 Unused code - Replies (1)

Rule 2.5 states "A project should not contain unused macro declaration".

Forum post https://www.misra.org.uk/forum/viewtopic...216&t=1571 acknowledges that Rule 2.5 should be "A project should not contain unused macro definition", however a change to "A project should not contain unused macro identifier" would cover both the original intent and also catch the following coding error without compromising rule decidability:
[code]
/* Macro containing coding error - macro parameter pin is unused */
#define SET_PIN(pin, polarity) \
((GPIO->PIN[pin_number] & ~PIN_Msk) | (polarity

Pages (107): « Previous 1 … 20 21 22 23 24 … 107 Next »

Search Forums

(Advanced Search)

Forum Statistics

» Members: 6,309
» Latest member: 1fuhd
» Forum threads: 1,066
» Forum posts: 2,933

Full Statistics

Online Users

There are currently 98 online users.
» 0 Member(s) | 94 Guest(s)
Bing, Facebook, Google, UptimeRobot

Latest Threads

13.2 Was TC2 correctly ap...
Forum: 8.13 Side effects
Last Post: misra-c
08-10-2026, 12:47 PM
» Replies: 1
» Views: 624

20.12 Does the stringific...
Forum: 8.20 Preprocessing directives
Last Post: misra-c
08-10-2026, 12:40 PM
» Replies: 1
» Views: 554

13.3 Should side effects ...
Forum: 8.13 Side effects
Last Post: misra-c
08-10-2026, 12:37 PM
» Replies: 1
» Views: 426

11.6 pointer to pointer t...
Forum: 8.11 Pointer type conversions
Last Post: misra-c
08-10-2026, 12:21 PM
» Replies: 2
» Views: 1,032

What is the UTLR of -1?
Forum: 8.10 The essential type model
Last Post: misra-c
08-10-2026, 12:15 PM
» Replies: 1
» Views: 597

10.3 Clarify if narrower ...
Forum: 8.10 The essential type model
Last Post: misra-c
08-10-2026, 11:57 AM
» Replies: 1
» Views: 508

It 8.12 intended to be so...
Forum: 8.8 Declarations and defnitions
Last Post: misra-c
08-10-2026, 11:50 AM
» Replies: 1
» Views: 455

Rule 0.1.1 Example f4
Forum: 4.0 Language independent issues
Last Post: cgpzs
07-10-2026, 11:07 AM
» Replies: 3
» Views: 720

Rule 6-2-2 Usage of std::...
Forum: 6.6 Statements (C++)
Last Post: misra cpp
25-09-2026, 05:43 PM
» Replies: 1
» Views: 435

M5-0-4 switch over unscop...
Forum: 6.5 Expressions (C++)
Last Post: misra cpp
25-09-2026, 01:00 PM
» Replies: 3
» Views: 532

Login
Username:
Password:
	Remember me Lost Password?

Welcome to the MISRA discussion forum