MISRA Discussion Forums
Portal

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

Username
  

Password
  

  MISRA C:2012 AMD3
Posted by: david ward - 05-12-2022, 09:36 PM - Forum: MISRA resources - No Replies

We are pleased to announce the publication of MISRA C:2012 Amendment 3 (MISRA C:2012 AMD3). This document provides additional updates for ISO/IEC 9899:2011/2018 with consideration of new C11/C18 features.

This amendment is intended to be used with MISRA C:2012 (Third Edition, First Revision) as revised and amended by:

  • MISRA C:2012 Technical Corrigendum 2, and
  • MISRA C:2012 Amendment 2
This amendment is also compatible with MISRA C:2012 (Third Edition) as revised and amended by:
  • MISRA C:2012 Technical Corrigendum 1, 
  • MISRA C:2012 Technical Corrigendum 2, 
  • MISRA C:2012 Amendment 1, and
  • MISRA C:2012 Amendment 2.



Attached Files
.pdf   MISRA C 2012 AMD3.pdf (Size: 1.35 MB / Downloads: 51)
Print this item

  A20-8-2 / A20-8-3 - Is returning a non-owning pointer always a violation?
Posted by: vanhuynh - 24-11-2022, 01:41 PM - Forum: AUTOSAR C++:2014 rules - Replies (4)

Hello,

Our team uses a static analysis tool for ASIL-B compliance. The tool warns about violation of rule A20-8-2/A20-8-3 when a non-owning pointer is returned from a function:

Code:
  template <uint64_t CAPACITY>
  class FixedCapacityBuffer {
      std::array<uint8_t, CAPACITY> buffer;
      uint64_t length;

  public:
      uint8_t* Data() const noexcept { return buffer.data(); } //////////////< Violation of rule A20-8-2/A20-8-3?

      // ...
  };

Code:
 
Rule A20-8-3: "A unique_ptr shall be used to represent exclusive ownership."
Rule A20-8-3: "A std::shared_ptr shall be used to represent shared ownership."

However, I do not want to express exclusive or shared ownership. Is the warning correct or a false-positive?

Print this item

  A12-1-1 - Does it apply to POD structs?
Posted by: cgpzs - 23-10-2022, 06:45 AM - Forum: AUTOSAR C++:2014 rules - Replies (5)

Hi,

Does A12-1-1 apply to POD structs? Example:

Code:
struct Foo
{
  int x;
  int y;
};

The members of `Foo` are by default uninitialized. Does A12-1-1 require `Foo` to explicitly initialize its members, like this?

Code:
struct Foo
Code:
{
Code:
  int x{};
Code:
  int y{};
Code:
};


Please note that the above change has some implications, namely that `Foo` is no longer trivial. As such, compilers will warn about performing `memcpy` operations on them. This is a problem for serializer/deserializer type of code.

Thanks!

Print this item

  8.2 Function types shall be in prototype form with named parameters
Posted by: sowisojh - 27-09-2022, 12:02 PM - Forum: 8.8 Declarations and defnitions - Replies (3)

Given is the following code:

Code:
myheader.h

/* define a type of a callback function */
typedef uint16_t(my_callback_fct_t)(uint16_t const *a);


myimplementation.c

#include "myheader.h"

/* function declaration of myCallbackFunction */
static my_callback_fct_t myCallbackFunction;

[...]

/* function definition of myCallbackFunction */
static uint16_t myCallbackFunction(uint16_t const *a)
{
  return (*a) + (uint16_t)1u;
}

Does the function declaration of myCallbackFunction in the above code comply with the Rule 8.2?
As the prototype specifies the parameters by usage of the type my_callback_fct_t and this prototype includes all the parameter and their names I would treat this as a correct prototype as requested by Rule 8.2. even though this is not explicitly listed as being compliant in the MISRA standard.

The background for this kind of function prototyping is to tie the function to an externally defined function prototype which will be used for callbacks in another part of the code.

kind regards
sowiso

Print this item

  How to handle Guidelines that are mentioned as 'Required' in 2012
Posted by: [email protected] - 26-09-2022, 06:43 AM - Forum: MISRA Compliance discussions - Replies (1)

Hello,
I am using MISRA 2012 to review the SW code(Both Auto code and Manual). 
I am bit confused to handle the the guidelines that are mentioned as 'Required'. 
I would like to know what are all the cases when the the rules can be deviated with reasonable justification. And what are all the cases when deviation is not at all accepted with any justification. 

Thank you!

Print this item

  A7-1-1 and function parameters
Posted by: mstaron - 31-08-2022, 01:03 PM - Forum: AUTOSAR C++:2014 rules - Replies (2)

The 'A7-1-1' uses the term: 'immutable data declaration'. This is not defined in the C ++ standard, so it is unclear if this rule applies to function parameters.

Code:
int f(int x)  // Is it Non-compliant?
{
  return x;
}
Print this item

  A5-2-6 about operands consisting of a sequence of only `&&` or `||`
Posted by: zhaohui - 19-08-2022, 06:21 AM - Forum: AUTOSAR C++:2014 rules - Replies (2)

Quote:A5-2-6 (Required) : The operands of a logical && or \\ shall be parenthesized if the operands contain binary operators.

What about those cases whose oeprands consists of either a sequence of only logical && or ||?
Code:
void f()
{
    int a, b, c, d;
    if ((a < b) || (b < c) || (c < d)) // compliant or noncompliant
    {
    }
}
This should be a exceptional case for MISRA C++-2008 Rule 5-2-1 ( Each operand of a logical && or || shall be a postfix-expression ), does this exception apply for A5-2-6 either?

Print this item

  Why example in Rule A5-0-2 is non-complient
Posted by: kafka - 27-07-2022, 07:13 PM - Forum: AUTOSAR C++:2014 rules - Replies (1)

Could someone please explain why the "if (u && (boolean1 <= boolean2));" in Rule A5-0-2 is non-compliant.

Print this item

  Why example in Rule 5-0-13 is non-compliant
Posted by: kafka - 27-07-2022, 07:13 PM - Forum: 6.5 Expressions (C++) - Replies (1)

Could someone please explain why the "if ( u8 && (bool_1 <= bool_2 ) )" in Rule 5-0-13 is non-compliant.

Print this item

  Strict aliasing rule
Posted by: suruena - 25-07-2022, 10:17 AM - Forum: 8.11 Pointer type conversions - No Replies

The Rule 11.3 (category Required) disallows the conversion between two pointers to different object types, indicating in the first paragraph the possible problems due to different alignment, and in the second paragraph that even if same alignment it is undefined behavior anyway (citing C99 section 6.5p7), except if conversion to pointer to a char type.

Even if the rule is technically correct, in my opinion readers will normally focus on the first paragraph, just analysing the alignment restrictions (and endianness) of the specific platform for justifying specific deviations (like using type punning through pointer conversion for needed format conversions). For example, justifying the conversion of a uint32_t into an array of two uint16_t, or a 32-bit float into a uint32_t. However, the part about undefined behavior is probably not highlighted enough, specially now that current compilers will take advantage of this undefined behavior to generate broken code due to the type aliasing analysis (reordering assignments or even removing code as the compiler is not required to consider the dependencies between those objects due to the undefined behavior, unless aliasing through a char pointer type or due to a few other exceptions).

I think it would be much more useful for the reader to mention the "strict aliasing rule" (as this is the term normally used to warn about these problems in technical forums) and the possibility to get "miscompiled" code at high optimization levels. Also, I think it would be very appreciated to give some guidance of possible standard-compliant solutions like using memcpy instead (moreover as the compiler will probably remove the call overhead if optimizations enabled), copying into an union (which may also be optimized by the compiler, not really generating any data copy) if the compiler is compliant with C99 T3, or even disabling the strict aliasing when compiling (like using -fno-strict-aliasing in GCC), in addition to the already mentioned access through a pointer to a char type.  Even if it cannot be ensured the universal adequacy of these solutions, the readers will be warned about sophisticated compilers and the strict aliasing rule, and will be aware about possible solutions available to be considered in their specific platform. Thank you very much.

Best regards,
Santiago

Print this item

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 435 online users.
» 0 Member(s) | 432 Guest(s)
Bing, DuckDuckGo, Google

Latest Threads
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
1 hour ago
» Replies: 0
» Views: 10
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 349
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 307
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,431
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,846
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,463
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,672
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,226
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 403
MISRA 2023 Test Suite
Forum: General Questions
Last Post: grigdon
14-10-2024, 01:27 PM
» Replies: 0
» Views: 182