MISRA Discussion Forums
Portal

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

Username
  

Password
  

  Rule 7.0.2: Unclear/questionable rationale
Posted by: cgpzs - 06-12-2024, 09:29 AM - Forum: 4.7 Standard conversions - Replies (1)

Hi,

Rule 7.0.2 bans any type of conversion to bool (implicit or explicit) anywhere in the code (with some exceptions). The rationale says:

"However, this interpretation may not be appropriate for APIs, such as POSIX, that do not use Boolean return values."

This sounds strange, why should modern C++17 code (that may not use C-style POSIX functions at all) be limited by this?

Could you show an example code that highlights how this is a problem and leads to unexpected behavior? For example, how is this code unsafe/can lead to unexpected results?

Code:
bool b1 = static_cast< bool >( 4 );  // Non-compliant

Conversion from fundamental types to bool is well-defined behavior as per [conv.bool]:

"A prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member type can be converted to a prvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true."

Thanks!

Print this item

  Rule 7.0.4 - exception for binary bitwise operators and constant operands?
Posted by: cgpzs - 05-12-2024, 01:06 PM - Forum: 4.7 Standard conversions - Replies (2)

Hi,

My interpretation of Rule 7.0.4 is that it does not allow this type of code:

Code:
my_function(FLAG_A | FLAG_B | FLAG_C);

This is quite frequent when interfacing with third-party as well as POSIX C APIs. Casting each argument to unsigned type would go in detriment of readability.

Would it make sense to add an exception for signed constants?

Thanks!

Print this item

  Rule 6.2.1: non-inline constexpr variables in headers?
Posted by: cgpzs - 22-11-2024, 10:11 AM - Forum: 4.6 Basic concepts - Replies (2)

Hi, 

Consider the following example:

Code:
// foo.h
constexpr int kFoo = 123;

inline int foo(int x)
{
  return x * kFoo;
}

// tu1.cpp
#include "foo.h"
int tu1() { return foo(1); }

// tu2.cpp
#include "foo.h"
int tu2() { return foo(2); }

Does the function "foo" violate Rule 6.2.1 in this context, given that kFoo is not a C++17 inline variable? 
Or would it violate 6.2.1 only if kFoo were ODR-used (for example, passed by reference)?

Thanks!

Print this item

  Rule 0.1.2
Posted by: stephanmuench - 21-11-2024, 01:12 PM - Forum: 4.0 Language independent issues - Replies (1)

Dear MISRA members,

I would have a question about MISRA C++:2023 Rule 0.1.2 which mentions in its rationale
"Overloaded operators are excluded from this rule because [...]"

Here, my question is whether in this scope, `operator()` should be considered to be a built-in operator.
Since to me, such one should instead be considered more of a normal function call.
Otherwise, it would undermine the rule's actual intention, which is to diagnose any unused return values of function calls, am I right?
Especially for modern C++ where plenty of code gets put into lambdas and/or std::function.

I would very happy if you could share some thoughts about this.

Thanks a lot in advance & best regards,
Stephan

Print this item

  A18-9-4
Posted by: cgpzs - 15-10-2024, 09:58 AM - Forum: AUTOSAR C++:2014 rules - Replies (2)

Hi!

I wonder if this code example technically violates A18-9-4?

Code:
#include <memory>

struct Foo
{
    explicit Foo(int);
};

int main()
{
    int val{};
    auto x = std::make_unique<Foo>(val);
    ++val; // non-compliant?
}

Since internally, std::make_unique takes the input arguments as "Args&&..." and std::forward's them into the constructor of the class.

Thanks!

Print this item

  MISRA 2023 Test Suite
Posted by: grigdon - 14-10-2024, 01:27 PM - Forum: General Questions - No Replies

Hi,

Is there a MISRA 2023 test suite? I'm looking for C code with violations to be used for static analysis tool validation.

Thanks

Gerry

Print this item

  MISRA C:2023 ADD4
Posted by: david ward - 11-10-2024, 07:41 PM - Forum: MISRA resources - No Replies

This Addendum to MISRA C:2023 sets out the coverage by MISRA C:2023 against the language-independent guidance of ISO/IEC 24772-1:2019 and the C language specific guidance of ISO/IEC 24772-3:2020



Attached Files
.pdf   MISRA C 2023 ADD4.pdf (Size: 364.7 KB / Downloads: 6)
Print this item

  MISRA C:2023 ADD2
Posted by: david ward - 11-10-2024, 07:40 PM - Forum: MISRA resources - No Replies

This Addendum to MISRA C:2023 sets out the coverage by MISRA C:2023 against ISO/IEC 17961, incorporating the 2016 technical corrigendum to the latter document.



Attached Files
.pdf   MISRA C 2023 ADD2.pdf (Size: 285.63 KB / Downloads: 6)
Print this item

  Rule 7.0.2: operator const char *()
Posted by: karos - 11-10-2024, 12:33 PM - Forum: 4.7 Standard conversions - Replies (2)

Hello,

Rule 7.0.2 has an exception for converting pointer to bool, and requires an explicit operator bool() for classes. But what if a class, let's say a wrapper class for strings, provides an operator const char *? Consider the following example:

Code:
class C
{
public:
    operator const char *() const;
};

void f(C c)
{
    if (c); // C is converted twice: C -> const char * -> bool
}

Shall the commented line be considered compliant with this rule (because each of the conversion steps by itself is compliant), or not (because as a whole it is the conversion of a class to bool without using an explicit operator bool)?

Print this item

  A8-4-5: are partial moves allowed?
Posted by: cgpzs - 01-10-2024, 12:28 PM - Forum: AUTOSAR C++:2014 rules - Replies (1)

Are partial moves allowed by A8-4-5? If not, why not?

For example, consider the following snippet from Effective Modern C++ (Meyers), Item 25, page 169:

Code:
class Widget {
public:
   Widget(Widget&& rhs)
   : name(std::move(rhs.name)),
     p(std::move(rhs.p))
   { … }
   …

// rhs is rvalue reference
private:
   std::string name;
   std::shared_ptr<SomeDataStructure> p;
};
Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,179
» Latest member: vixat32074
» Forum threads: 1,000
» Forum posts: 2,760

Full Statistics

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

Latest Threads
Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: cgpzs
Yesterday, 02:38 PM
» Replies: 2
» Views: 156
Rule 7.0.4 - exception fo...
Forum: 4.7 Standard conversions
Last Post: cgpzs
Yesterday, 02:36 PM
» Replies: 2
» Views: 108
Rule 7.0.2: Unclear/quest...
Forum: 4.7 Standard conversions
Last Post: misra cpp
Yesterday, 02:24 PM
» Replies: 1
» Views: 116
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: misra cpp
Yesterday, 02:05 PM
» Replies: 1
» Views: 160
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 613
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 504
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,611
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 9,030
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,796
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,850