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

Username
  

Password
  





  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 - Replies (1)

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 (3)

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

  10.3 "promoted type" of controlling expression
Posted by: grunwald - 27-02-2020, 02:45 PM - Forum: 8.10 The essential type model - Replies (1)

What exactly is meant by Rule 10.3 using "promoted type" in "The conversion of the constant expression in a switch statement’s case label to the promoted type of the controlling expression." ?
Using the promoted type kinds of contradicts the rule title, which is using essential types.

The following examples assume 10.3 uses the standard C type (after integer promotions) for the controlling expression.
Does the promotion also apply to the case labels, or do we keep using the essential type there? Assuming we keep using the essential type for case labels, that leads to some surprising violations:

Code:
uint8_t a = 1;
switch (a) { // type promoted to "signed int"
  case 1u:  // 10.3 violation because 1u is essentially unsigned, but the controlling expression is promoted to an essentially signed type?
  case -200: // compliant with 10.3, even though the case is impossible to reach due to the sign mismatch?
      break;
}


Is there a way to write the following switch that is compliant on both 16-bit and 32-bit machines?
Code:
uint16_t num = ...;
switch (num >> 1u) { // uint16_t promotes to 'signed int' or 'unsigned int' depending on "sizeof(uint16_t) == sizeof(int)"
  case 1u:   // 10.3 violation where sizeof(int)>2, because the controlling expression is promoted to an essentially signed type?
  case (uint16_t)2u:  // 10.3 violation where sizeof(int)>2, because the controlling expression is promoted to an essentially signed type?
  case 2:  // I guess signed literals work in all cases, thanks to exception 3.
      break;
}

It would make more sense to use the essential type for both controlling expression and labels; or use the standard type for both.

Print this item

  MISRA C:2012 AMD2 and MISRA Compliance:2020 available
Posted by: david ward - 25-02-2020, 07:18 AM - Forum: Announcements - No Replies

MISRA C:2012 Amendment 2 (which brings C11 into scope) and MISRA Compliance:2020 (which becomes mandatory as the framework for compliance with MISRA C and future releases of MISRA coding guidelines) are now available as free downloads from the "Resources" section of this Bulletin Board.

Print this item

  MISRA Compliance:2020
Posted by: david ward - 25-02-2020, 07:16 AM - Forum: MISRA resources - No Replies

Significant work has taken place within the MISRA C and MISRA C++ Working Groups since the initial release of MISRA Compliance in 2016, with one of the outcomes being that all future releases of MISRA Guidelines will mandate the use of MISRA Compliance.

Up to this point, the MISRA Guideline documents have all included content related to the various MISRA compliance activities. This update to MISRA Compliance enhances Section 2.2 (now titled “Framework”) of Chapter 2 (now titled “The software development process”), completing the definition of what must be covered within the software development process when making a claim of MISRA compliance. This is mainly a “house-keeping” exercise, allowing the compliance-related content to be replaced by references to this document, ensuring consistency among the MISRA Guidelines whilst reducing the effort required in their maintenance.



Attached Files
.pdf   MISRA Compliance 2020.pdf (Size: 302.07 KB / Downloads: 76)
Print this item

  MISRA C:2012 Amendment 2
Posted by: david ward - 25-02-2020, 07:14 AM - Forum: MISRA resources - No Replies

An updated edition of the C Standard, commonly referred to as “C11”, was released just as MISRA C:2012 was being prepared for publication, meaning it arrived too late for the MISRA C Working Group to take it into consideration.

As the adoption of C11 has become more widespread, the MISRA C Working Group have decided that it is now time to address this new edition of the C Standard, support for which will be implemented by means of a series of amendments to MISRA C:2012. This document amends MISRA C:2012 as required to introduce support for ISO/IEC 9899:2011. Subsequent amendments will be used to introduce specific guidance for the features introduced by ISO/IEC 9899:2011.

In the three years since its publication, the additional guidance provided by MISRA Compliance has been increasingly adopted. The MISRA C Working Group have decided that now is the time to upgrade this guidance from optional to be an integral part of the MISRA C lifecycle. Therefore, this document amends MISRA C:2012 to do that.



Attached Files
.pdf   MISRA C 2012 AMD2.pdf (Size: 455.86 KB / Downloads: 114)
Print this item

  Rule 10.6 An expression shall not be assigned to a wider type
Posted by: LordMordac - 27-01-2020, 11:47 PM - Forum: 8.10 The essential type model - Replies (1)

The full rule title is:

Quote:The value of a composite expression shall not be assigned to an object with a wider essential type

I am having a lively debate with my scanner vendor about the quality of their scans. The following example code is generating the commented violation:
[code]
static inline uint32_t bit32 (uint32_t pos)
{
static const uint32_t mask = 31U;
static const uint32_t one = 1U;

// Event misra_c_2012_rule_10_6_violation: Assigning composite expression "1U

Print this item

  Signal naming convention in MISRA guidelines
Posted by: ikostas_arrival - 21-01-2020, 09:31 AM - Forum: MISRA AC SLSF discussions - Replies (1)

Hi,

That is my first message on this bulletin, so I am not sure whether this is the right place for my question. If not please direct me to the right thread.

I work in the automotive sector and more specifically in safety critical automotive control design with Simulink etc. So far in my team, we haven't started using an established signal name convention in Simulink that complies with a standard like MISRA. My question is, do you know if there is any of the MISRA documents that provides signal name convention for automotive systems?

In Autosar there is such a keyword list as you can see in the end of this document https://www.autosar.org/fileadmin/user_u...deling.pdf

For example if I want to name a signal with the name vehicle longitudinal velocity. Should it be vhllongvel or vehlngvl or vehllongvel etc. You get the picture.

thanks in advance,

ILIAS

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 265 online users.
» 0 Member(s) | 262 Guest(s)
Bing, Google, Yandex

Latest Threads
Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: cgpzs
3 hours ago
» Replies: 0
» Views: 6
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
Yesterday, 01:12 PM
» Replies: 0
» Views: 29
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,434
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,473
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,675
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: 410