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

Username
  

Password
  





  Rule 13.4 For statement operand assignment
Posted by: shaw - 07-01-2022, 10:46 AM - Forum: 8.13 Side effects - Replies (1)

The third operand of the for statement has an assignment. Does the calculation violate the result that the assignment operator should not be used?

for ( pos = (&dev->list)->next, q = pos->next; pos != (&dev->list); pos = q, q = pos->next ) {/*        */}

Print this item

  9-3-3 and interfaces enforced via templates instead of virtual functions
Posted by: cgpzs - 15-12-2021, 09:34 AM - Forum: 6.9 Classes (C++) - Replies (5)

Hi,

We are having trouble following Rule M9-3-3 when implementing interfaces using templates, similarly to the idea of "named requirements". I have read a similar post about this rule here and it's stated that the rule will be revised to also take the "override set" of virtual functions into account, making sure a function should be made const only if the whole "override set" can be made const.

Sometimes it might not be feasible to implement interfaces via virtual functions, and templates can be used to achieve the same result instead:

Code:
template <typename FooT>
void foo(FooT& f)
{
   f.run();
}


This pattern is commonly used e.g. in static dependency injection. We can pass any type `FooT` as long as it fulfills the interface `FooT::run`. For some types, `run` could be made const, but not all of them, therefore we get warnings from our static analyzers in such functions.

Will you consider this use case in the next revision of the rule? How do you suggest we work with it?

Thanks!

Print this item

  Rule A13-2-3 - Relational operator shall return a boolean value
Posted by: DelayShot - 08-12-2021, 09:08 AM - Forum: AUTOSAR C++:2014 rules - Replies (1)

Hi, 

the rule mentioned in the title states:

Rule A13-2-3 (required, implementation, automated) A relational operator shall return a boolean value.

The AUTOSAR document then proceeds to give some examples where the compliant ones have the function declaration stating the return type as `bool`.

So, to be compliant with the rule, is it necessary to just check the return type of the function? Or should we try to evaluate the type of the object returned in the return statement inside the function in order to see if it is an actual `bool` and that no implicit casts were used? 

By just looking at the examples, based also on where the `// Compliant` and `// Non-compliant` comments are, it seems to me that checking the function type signature in its prototype is enough.

What do you think?

Thanks.

Print this item

  CWE Coverage by MISRA
Posted by: susanne.goldammer - 30-11-2021, 12:23 PM - Forum: General Questions - Replies (1)

Hi all,

i am currently searching for a CWE coverage list, means which CWEs listed under https://cwe.mitre.org/data/definitions/1000.html (Research concepts, means all) are actually covered by MISRA C? Is there such a list available?  

Thank you in advance.

Best regards
Susanne

Print this item

  5-2-12 - Does the rule apply for braced-init-list arg to initializer_list parameter?
Posted by: DavidFriberg - 24-11-2021, 03:23 PM - Forum: 6.5 Expressions (C++) - Replies (1)

Hi,

Rule 5-2-12 covers array to pointer decay in a function call:

Quote:Rule 5-2-12 (required, implementation, automated) An identifier with array type passed as a function argument shall not decay to a pointer.

This rule has been brought over to the AUTOSAR C++14 guidelines in verbatim (as M5-2-12), where it applies to more modern C++.

Now, an object of type std::initializer_list<E> (for some type E) is, as per [dcl.init.list]/5 (N4140/C++14), defined to be constructible from a braced-init-list as follows:

Quote:An object of type std::initializer_list<E> is constructed from an initializer list as if the implementation allocated a temporary array of N elements of type const E, where N is the number of elements in the initializer list. Each element of that array is copy-initialized with the corresponding element of the initializer list, and the std::initializer_list<E> object is constructed to refer to that array.

Some compilers (correctly within their implementation freedom) implements the constructor of their std::initializer_list class template with two arguments: a begin iterator for the "as if an array" argument, and a size of the list (automagically provided). 

Our static analyzer for AUTOSAR C++14 (whilst noting that this is a pre-C++11 rule) uses this to argue that any occasion where a braced-init-list is used as argument to a (compatible) function parameter that is a specialization of std::initializer_list is a violation of M5-2-12, essentially meaning we can neither use any of the std::initializer_list constructors from our in-house container classes, nor act as clients for many of the standard library's container classes (say under the assumption that we have an certified subset STL available):
Code:
#include <initializer_list>
#include <vector>

namespace rule_m5_2_12
{

/// @brief Docs.
template <typename ScalarT, std::int32_t N>
class StaticVector final
{
public:
    /// @brief Docs.
    /// @param list Docs.
    StaticVector(std::initializer_list<ScalarT> const list) noexcept : data_{} {}
private:
    /// Docs.
    ScalarT data_[N];
};

inline void f()
{
    constexpr std::int32_t kSize{3};

    // "Array type is used as a pointer type argument in the function call."
    auto const a = StaticVector<std::int32_t, kSize>{1, 2, 3};  // M5-2-12 violation
    auto const b = std::vector<std::int32_t>({1, 2, 3});        // M5-2-12 violation

    // ...
}

}  // namespace rule_m5_2_12

Is the intent that Rule M5-2-12 (in the modern C++ world) should prohibit any client side (braced-init-list argument) usage of std::initializer_list<E> function parameters?

Thanks!

Print this item

  A5-0-4 - Does the rule apply to range-based for loops?
Posted by: cgpzs - 04-11-2021, 08:50 AM - Forum: AUTOSAR C++:2014 rules - Replies (3)

Hi,

Does rule A5-0-4 apply to range-based `for` loops? Technically, range-based `for` loops are syntactic sugar for iterator-based loops, so technically pointer arithmetic is happening under the hood. Consider this example:

Code:
struct Foo /* final */
{
    int x;
    int y;
};

std::vector<Foo> v;

// Fill v...


for (x : v)  // A5-0-4 violated here?
{
   ...
}

The easy solution is to make `Foo` `final`, of course. But what about classes we don't have control over, like STL classes?


Code:
std::vector<std::vector<int>>
std::vector<std::unique_ptr<int>>

A range-based `for` loop would be performing pointer arithmetic over `std::vector<int>*` and `std::unique_ptr<int>*`. These classes are not `final`. Would that then violate A5-0-4?

Our static analyzer is flagging these use cases as non-compliant, but it feels overly strict. What's your view on this?

Thanks!

Print this item

  A3-1-5 - Rationale and example inconsistent with rule headline?
Posted by: cgpzs - 04-11-2021, 07:13 AM - Forum: AUTOSAR C++:2014 rules - Replies (3)

Hi!

We have some confusion about rule A3-1-5:

A function definition shall only be placed in a class definition if (1) the
function is intended to be inlined (2) it is a member function template (3)
it is a member function of a class template.


As non-native English speakers, the "shall only" part of the sentence is not exactly clear to us. We can think of 2 interpretations:

1) A function definition may be placed in the class definition only if it fulfills any of the 3 points.
2) If a function definition fulfills any of the 3 points, then it shall (must) be placed in the class definition.

The rationale and examples seem to implement interpretation 2), but we believe interpretation 1) makes more sense.

Consider the following use case of a template class that doesn't need to be generic, i.e. it's only meant to be used for a handful of types. This pattern is widely used for static dependency injection:

Code:
// foo.h

template <typename Impl>
class Foo
{
public:
    // Long, complicated function with many dependencies:
    // implement in foo.cpp to keep header clean, speed up
    // compilation time, etc, etc.
    void run();

private:
    Impl impl_{};
};

// foo.cpp
#include "foo.h"

template <typename Impl>
void Foo<Impl>::run()
{
    // Implementation...
}


// Explicit instantiation for the only 2 possible cases
template class Foo<RealImpl>;
template class Foo<MockImpl>;

As you can see, this is a perfectly valid use case where a template class can be implemented in a .cpp file, with all the advantages that come with this.

Now, A3-1-5, the way it's described in the rationale and examples, would forbid this use case, and force us to move hundreds of lines of implementation of perfectly valid code from the source file to the header file. This in turn clutters an otherwise clean header, greatly increases compilation time, etc, which is pretty bad. That's why best practices always recommend to put the implementation in the source file as much as possible.

The rationale for the rule is rather weak, in our opinion. "template syntax elements (e.g. parameter list), which makes code less difficult to read and maintain." Readability is hurt much more if we clutter the header file with implementation details. Besides, it's not "difficult to maintain", as the compiler will easily catch any mismatch between header and source (just like it would for a non-template class).

Therefore here's my question - is the rationale and examples for A3-1-5 what they intended to be, or was there some confusion in the interpretation of the "shall only" part of the rule, and therefore it should be corrected? Should we interpret the rule as 1) or 2) above?

Thanks a lot!

Print this item

  New forum for AUTOSAR rule questions
Posted by: david ward - 03-11-2021, 03:10 PM - Forum: AUTOSAR C++:2014 rules - No Replies

Many of you will be aware that MISRA took over ownership of the AUTOSAR C++:2014 rules and is continuing work to integrate these in the upcoming revision of MISRA C++.

Following a recent question we've created this forum for people to ask questions about the AUTOSAR rules and help ensure consistency in answers as we move towards the next revision of MISRA C++.

Initially we've created a single forum but may add sub-topics if this becomes necessary.

Print this item

  AUTOSAR C++14 handed over to MISRA - may we ask AUTOSAR C++14 questions here?
Posted by: cgpzs - 28-10-2021, 06:16 AM - Forum: General Questions - Replies (2)

Hi!

The following is stated in the AUTOSAR C++14 guidelines:

> This specification is obsolete and will be removed from the standard in an upcoming
release. The work has been handed over to MISRA and will no longer be maintained
by AUTOSAR.


Since "the work of AUTOSAR C++14 has been handed over  to MISRA", would it make sense/be OK for us to ask questions about AUTOSAR C++14 in this forum? There are some rules that require some clarification and there's no way to contact the authors. 

I know that MISRA is currently working on a new set of C++ guidelines for 202x, combining the work done in the previous MISRA releases and AUTOSAR C++14. I believe being able to ask about AUTOSAR C++14 here would provide valuable feedback to MISRA to incorporate in the new guidelines.

Thanks!

Print this item

  6-5-2 and 6-5-4 on while loop checking std::vector::empty()
Posted by: cgpzs - 26-10-2021, 12:14 PM - Forum: 6.6 Statements (C++) - Replies (5)

Hi,

We have a static analyzer that is reporting warnings related to 6-5-2 and 6-5-4 in the following code:

Code:
    std::vector<std::int32_t> v{};
    // Fill vector
    // ...
  
    // Consume vector
    while (!v.empty())  // <<< 6-5-2, 6-5-4 violated here?
    {
        std::int32_t const value{v.back()};
        v.pop_back();
        std::cout << value << "\n";
    }

The warning is that the "loop counter v" is not compared against a relational operator (6-5-2) nor is it modified via ++ et al. (6-5-4).

The static analysis tool vendor claims this is not a false positive and indeed it's required by the MISRA rules.

Could you shed some light as to whether the code above is violating 6-5-2 and 6-5-4? Is "v" really a loop counter as per the MISRA definition? One could argue that the loop counter is the private member std::vector::__size, but is that really the scope of this rule?

This code pattern is very typical when implementing e.g. graph search, having a list of Nodes and inspecting them one by one until a condition is reached or the list of nodes is empty. The list of nodes can typically grow while inspecting each node, so iterator-based searches are not a good implementation alternative.

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

Latest Threads
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
11 hours ago
» Replies: 0
» Views: 24
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: 310
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,432
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,847
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,470
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,674
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,230
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 405
MISRA 2023 Test Suite
Forum: General Questions
Last Post: grigdon
14-10-2024, 01:27 PM
» Replies: 0
» Views: 182