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

Username
  

Password
  





  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?

Print this item

  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

Print this item

  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.

Print this item

  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!

Print this item

  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;
}

Print this item

  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".

Print this item

  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

Print this item

  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

Print this item

  Shall Rule 21.1 apply to the both paths of conditional preprocessing
Posted by: chenzhuowansui - 04-03-2020, 02:28 AM - Forum: 8.21 Standard libraries - No Replies

Hi there,
Rule 21.1 doesn't mention anything about preprocessing, so given the following code

Code:
#define ABC 345

#ifdef ABC
#define _XYZ 0xFFFFFFFF    //defect1
#else
#define _XYZ 0xF0000000  //defect2
#endif

shall we report both the above defects or only the one(defec1) in the true path?

thanks

Print this item

  When will MISRA C:2012 permits be available?
Posted by: Qiong - 03-03-2020, 02:18 PM - Forum: General Questions - Replies (1)

When will MISRA C:2012 permits be available? MISRA Compliance:2020 section 4.3 (page 13) mentioned "Public deviation permits, published by MISRA". We would like to see the permits list for MISRA C:2012 not for MISRA C:2004.

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 5,681
» Latest member: DelayShot
» Forum threads: 880
» Forum posts: 2,427

Full Statistics

Online Users
There are currently 77 online users.
» 0 Member(s) | 75 Guest(s)
Bing, Google

Latest Threads
MISRA C++ new version
Forum: C++ Announcements
Last Post: david ward
30-11-2021, 03:53 PM
» Replies: 7
» Views: 10,932
CWE Coverage by MISRA
Forum: General Questions
Last Post: susanne.goldammer
30-11-2021, 12:23 PM
» Replies: 0
» Views: 24
Rule8.9 applicability to ...
Forum: 8.8 Declarations and defnitions
Last Post: misra-c
27-11-2021, 11:10 AM
» Replies: 1
» Views: 229
Rule 14.3 and preprocesso...
Forum: 8.14 Control statement expressions
Last Post: misra-c
27-11-2021, 11:00 AM
» Replies: 1
» Views: 151
Rule 17.4 and main
Forum: 8.17 Functions
Last Post: misra-c
27-11-2021, 09:58 AM
» Replies: 1
» Views: 166
2.2 Dead code, 'operation...
Forum: 8.2 Unused code
Last Post: misra-c
27-11-2021, 09:18 AM
» Replies: 1
» Views: 170
for loop iterator being c...
Forum: 8.10 The essential type model
Last Post: misra-c
27-11-2021, 09:10 AM
» Replies: 1
» Views: 184
5-2-12 - Does the rule ap...
Forum: 6.5 Expressions (C++)
Last Post: DavidFriberg
24-11-2021, 03:23 PM
» Replies: 0
» Views: 67
6-5-2 and 6-5-4 on while ...
Forum: 6.6 Statements (C++)
Last Post: cgpzs
18-11-2021, 12:09 PM
» Replies: 4
» Views: 244
A3-1-5 - Rationale and ex...
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
15-11-2021, 08:45 AM
» Replies: 2
» Views: 191