MISRA Discussion Forums

Welcome, Guest

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

Rule 0.0.1

Posted by: gdavis - 24-05-2024, 05:20 AM - Forum: 4.0 Language independent issues - Replies (1)

Hello,

I apologize for this basic question, but can somebody please walk me through the first first five lines of MISRA C++ 2023 Rule 0.0.1?

bool f0();

int32_t f1( int32_t c, int32_t &res )
{
if ( false && f0() ) { } // Compliant - statement is considered to be reachable
...

In particular, why is the empty block statement ("{ }") considered to be reachable? My thinking is:

The condition of the if statement is considered a constant expression in C++17, one that evaluates to false. Therefore, we follow the third bullet point:

The blocks linked by the edges from a condition of a selection-statement or an iteration-statement are all considered reachable, except when the condition is a constant expression, in which case only the blocks linked by edges selected by the condition are considered reachable.

So, this seems to me that we should consider the empty block statement to be unreachable.

Also, what is the purpose of the first two bullet points:

Both operands of a reachable logical AND (&&) or logical OR (||) operator are considered reachable
All three operands of a reachable conditional operator ( ? : ) are considered reachable

Rule 0.0.1 is concerned with statements, so I don't see how subexpressions matter unless these rules are meant to convey that an expression such as ( false && f0() ) is potentially throwing and/or not a constant expression (for the purposes of this rule).. But, I feel like I may be reading too much into this.

Thank you in advance.

Exemplar Suite for MISRA C++

Posted by: gdavis - 21-05-2024, 09:58 PM - Forum: General questions - Replies (1)

	Hello, Is there an Exemplar suite for MISRA C++ (either 2023 or 2008?). Looking around, I could not find one, but I wanted to check to make sure I am not missing anything. Thank you! Best Regards, -Greg

Application of Rule 15.0.1 to Abstract Interface Classes

Posted by: nehalpatel - 14-05-2024, 06:19 PM - Forum: 4.15 Special member functions - Replies (2)

It seems rule 15.0.1 has conflicting requirements for pure virtual / abstract classes with no data members. e.g. if we create the following classes:

Code:
class CanMessage {

public:

  CanMessage();

  // Required for inheritance

  virtual ~CanMessage() = default;

  // Want to move and copy through derived classes

  CanMessage(const CanMessage&) noexcept = default;

  CanMessage(CanMessage&&) noexcept = default;

  CanMessage& operator=(const CanMessage&) & noexcept = default;

  CanMessage& operator=(CanMessage&&) & noexcept = default;

  virtual uint32_t Id() = 0;

  virtual uint8_t DataLength() = 0;

  virtual std::span<std::byte> Data() = 0;

};

class CanClassicMessage : public CanMessage {

public:

  CanClassicMessage(uint32_t id, uint8_t data_length) : CanMessage{}, id_{id} data_length_{data_length} {}

  ~CanClassicMessage() noexcept override = default;

  CanClassicMessage(const CanClassicMessage&) noexcept = default;

  CanClassicMessage(CanClassicMessage&&) noexcept = default;

  CanClassicMessage& operator=(const CanClassicMessage&) & noexcept = default;

  CanClassicMessage& operator=(CanClassicMessage&&) & noexcept = default;

  uint32_t Id() override { return id_; }

  uint8_t DataLength() override { return data_length_; }

  std::span<std::byte> Data() { return data_; }

private:

  uint32_t id_;

  uint8_t data_length_;

  std::array<std::byte, 8> data_;

};

class CanFDMessage : public CanMessage {

public:

  CanFDMessage(uint32_t id, uint8_t data_length) : CanMessage{}, id_{id} data_length_{data_length} {}

  ~CanFDMessage() noexcept override = default;

  CanFDMessage(const CanFDMessage&) noexcept = default;

  CanFDMessage(CanFDMessage&&) noexcept = default;

  CanFDMessage& operator=(const CanFDMessage&) & noexcept = default;

  CanFDMessage& operator=(CanFDMessage&&) & noexcept = default;

  uint32_t Id() override { return id_; }

  uint8_t DataLength() override { return data_length_; }

  std::span<std::byte> Data() { return data_; }

private:

  uint32_t id_;

  uint8_t data_length_;

  std::array<std::byte, 64> data_;

}

Per the rule, we either need

a protected non-virtual destructor.
Unmovable class that has a public virtual destructor.

However these prevent us from being able to create a std::unique_ptr to the base class (and allow the derived classes to manage their data through their destructors), or prevents us from being able to copy or move one CanClassicMessage to another CanClassicMessage, if the base copy/move constructors are deleted.

There is an exception for Aggreagate types, but it seems there needs to be an other one for an Interface/Abstract class which holds no data.

A13-5-4 opposite operator clarification

Posted by: aromauld - 26-04-2024, 03:34 PM - Forum: AUTOSAR C++:2014 rules - Replies (1)

We would like to get clarification on what "opposite operators" means.

The referenced JSF guideline says (such as == and !=) which implies there are others, but there are no examples present other than "!= and ==".

Presumably this includes relational operators, but it doesn't discuss how. This rule would seemingly imply that <= should be implemented using >=. But would this mean that it is considered non-compliant to implement it with operator >?

Code:
inline bool operator<=(const X& lhs, const X& rhs) { return !(lhs > rhs); }

Are relational operators allowed to call any other relational operators? Are there any other pairings that are considered opposites for this rule?

C++17 [[fallthrough]]; attribute and (Rule 6-4-3 and Rule 6-4-5)

Posted by: mshawa - 22-04-2024, 06:29 PM - Forum: 6.6 Statements (C++) - Replies (1)

	Given the response from: Rule 6-2-3 and C++17 [[fallthrough]]; attribute (misra.org.uk) Should Rule 6-4-3(A switch statement shall be a well-formed switch statement) and Rule 6-4-5(An unconditional throw or break statement shall terminate every non-empty switch-clause) also have an exception for the [[fallthrough]]; attribute when used in an empty switch case?

Further guidance on MISRA-C 2012 Rule 10.6

Posted by: mshawa - 09-04-2024, 02:29 PM - Forum: 8.10 The essential type model - Replies (1)

MISRA-C 2012 D.3 states that UTLR/STLR rules are only applied to integer constant expressions for operators that explicitly specify this in D.7. D.7 further states that the essential type is the standard type unless otherwise listed and does not specify a non-standard essential type for sizeof.

Given the following example:

Code:
typedef unsigned int uint32_t;

typedef unsigned short uint16_t;

extern uint16_t u16;

extern uint32_t u32;

extern void foo( void );

void foo( void ) {

    uint32_t case1 = (sizeof(uint32_t) + sizeof(uint32_t)) + u16; /*Case 1*/

    uint32_t case2 = u32 + u32 + u16; /*Case 2*/

    uint32_t case3 = sizeof(uint32_t) + (sizeof(uint32_t) + u16);/*Case 3*/

    uint32_t case4 = sizeof(uint32_t) + u16 + sizeof(uint32_t); /*Case 4*/

}

Which of the cases violates Rule 10.6 while providing the rationale?

MISRA AC SLSF:2023 AMD1

Posted by: david ward - 05-04-2024, 01:56 PM - Forum: MISRA AC resources - No Replies

	This Amendment to MISRA AC SLSF:2023 contains modifications that bring the guidelines up to date for MATLAB release R2023b Attached Files MISRA AC SLSF 2023 AMD1.pdf (Size: 444.31 KB / Downloads: 9)

Rule 6-2-3 and C++17 [[fallthrough]]; attribute

Posted by: kafka - 27-03-2024, 02:44 PM - Forum: 6.6 Statements (C++) - Replies (1)

	Should the C++17 [[fallthrough]]; attribute be given an exception for MISRA C++ 2008 Rule 6-2-3 (a null statement shall appear on a line by itself)?

10.2.3 Amplification

Posted by: hahn - 26-03-2024, 03:08 PM - Forum: 4.10 Declarations - Replies (3)

Hi,

I find the amplification of rule 10.2.3 confusing.

In general I wonder what the difference to a simple "no implicit conversion from unscoped enumeration type without underlying type to numeric type" (plus the exception for static_cast in bullet point 3) is?

In particular, as example, for the following code

Code:
enum E {E1, E2};

int f(int);

E operator+(E, E);

int main() {

  E e = E1;

  f(e); // Compliant? (1)

  e = e + e; // Non-compliant (2)

}

I wonder whether (1) should be compliant or not. At least it is not listed in the amplification, but seems like a problematic case anyway.
In turn, should (2) be non-compliant as operands to "arithmetic operator" are explicitly listed in the amplification, while I think this case is absolutely fine.

It would be great to get a clarification on what the rule intends.

Rule 7.0.5 Example potential typo

Posted by: danix800 - 21-03-2024, 01:57 PM - Forum: 4.7 Standard conversions - Replies (1)

```c
constexpr int32_t fn( int32_t i )
{
return i * i;
}

u8 + fn( 10 ) // Compliant by exception #1
```

Is u8 a typo? Reasonable one might be 'u32 + fn(10)'?

u8 << 2 is non-compliant, so should u8 + f(10), this should be a typo.

Pages (100): « Previous 1 2 3 4 5 6 … 100 Next »

Search Forums

(Advanced Search)

Forum Statistics

» Members: 6,180
» Latest member: nweissnerdelta
» Forum threads: 1,004
» Forum posts: 2,768

Full Statistics

Online Users

There are currently 655 online users.
» 0 Member(s) | 652 Guest(s)
Applebot, Bing, Google

Latest Threads

MISRA AC SLSF:2023 AMD3
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
Yesterday, 10:58 AM
» Replies: 0
» Views: 18

MISRA AC SLSF:2023 AMD3
Forum: MISRA AC resources
Last Post: misra-ac
Yesterday, 10:57 AM
» Replies: 0
» Views: 19

Rule 7.0.4 - exception fo...
Forum: 4.7 Standard conversions
Last Post: misra cpp
10-01-2025, 02:26 PM
» Replies: 4
» Views: 401

rule 7.0.5: clarification...
Forum: 4.7 Standard conversions
Last Post: misra cpp
10-01-2025, 02:11 PM
» Replies: 1
» Views: 96

Rule 7.0.6 - why the requ...
Forum: 4.7 Standard conversions
Last Post: misra cpp
10-01-2025, 01:24 PM
» Replies: 1
» Views: 53

Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: cgpzs
20-12-2024, 02:38 PM
» Replies: 2
» Views: 424

Rule 7.0.2: Unclear/quest...
Forum: 4.7 Standard conversions
Last Post: misra cpp
20-12-2024, 02:24 PM
» Replies: 1
» Views: 320

Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: misra cpp
20-12-2024, 02:05 PM
» Replies: 1
» Views: 322

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

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

Login
Username:
Password:
	Remember me Lost Password?

Welcome to the MISRA discussion forum