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

Username
  

Password
  





  M9-3-1 and std::span-like classes
Posted by: cgpzs - 18-02-2022, 09:42 AM - Forum: 6.9 Classes (C++) - Replies (3)

Hi,

Our static analyzer is reporting a violation of M9-3-1 in the following backport of C++20's `std:Confusedpan`:

Code:
template <typename T>
class Span
{
public:
   Span(T* const ptr, std::size_t size) :
      data_{ptr},
      size_{size}
   {}

T* data() const { return data_; }  // M9-3-1 reported here

private:
   T* data_;
   std::size_t size_;
};

int main()
{
    std::array<int, 3> arr{1,2,3};
    Span<int> s{arr.data(), arr.size()};
}


The `Span` class is merely a non-owning wrapper around a memory buffer. Furthermore, the `data()` function is not returning a reference to any class member, it's returning a copy of a class member. 

Would you say M9-3-1 is violated in this example?

Thanks!

Print this item

  M5-0-15 + range-based for loops
Posted by: cgpzs - 15-02-2022, 12:25 PM - Forum: 6.5 Expressions (C++) - Replies (3)

Hi,

Our static analyzer is reporting M5-0-15 "this is using pointer arithmetic" in the following code:

Code:
int x[3] = {1,2,3};

int z = 0;
for (int y : x)  // M5-0-15 reported here
{
    z += y;
}

Most likely due to the range-based for loop expanding to an iterator-based for loop.

However, we would argue the MISRA rules apply to code written by users, not code generated by the compiler behind the scenes. 

What do you think, is the above code violating M5-0-15?

Thanks!

Print this item

  Side effects in floating point comparisons
Posted by: gdavis - 13-01-2022, 09:27 PM - Forum: 8.13 Side effects - Replies (1)

Hello,

A user is surprised that his compiler diagnoses the following as being a violation of MISRA 2012 13.5:

int in_range(double a)
{
    int result = 0;
    if (a >= 10.0 && a <= 20.0) {
        result = 1;
    }
    return result;
}

The reasoning behind the diagnostic is that with C99, floating point status bits (if implemented) are considered part of the program state, so floating point operations have implicit side effects.  See the footnote in C99 5.1.2.3.


This kind of goes back to Directive 1.1 and various decisions about floating point.

Does everyone agree that this should be considered a violation?  I would appreciate any other thoughts you may have.

Thanks,

-Greg

Print this item

  A20-8-6
Posted by: martin.m.dowie - 12-01-2022, 09:35 AM - Forum: AUTOSAR C++:2014 rules - Replies (1)

What is the preferred method of assigning to a local member data of type std::shared_ptr<T>?

Given the code below, are the lines indicated as A20-8-6 non-compliant really so and why? We can understand C2 (types match exactly). We can understand C4 (types match exactly and the member data is of std::shared_ptr<T>&.

The class C1 we believe is non-compliant but we can't justify ourselves of the reason why.

Is the rule trying to enforce 3 e) from GoTW #91 (https://herbsutter.com/2013/06/05/gotw-9...arameters/)?

Code:
struct S {};

class C1 {
    std::shared_ptr<S> s;
public:
    C1(const std::shared_ptr<S>& aS) : s(aS) {} // A20-8-6 non-compliant
};

class C2 {
    std::shared_ptr<S> s;
public:
    C2(std::shared_ptr<S> aS) : s(aS) {} // OK
};

class C3 {
    std::shared_ptr<S> s;
public:
    C3(std::shared_ptr<S>& aS) : s(aS) {} // A20-8-6 non-compliant
};

class C4 {
    const std::shared_ptr<S>& s;
public:
    C4(const std::shared_ptr<S>& aS) : s(aS) {} // OK
};

void f () {
    auto s = std::make_shared<S>();
    C1 c1(std::make_shared<S>());
    C2 c2(std::make_shared<S>());
    C3 c3(s);
    C4 c4(std::make_shared<S>());
}

Print this item

  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

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,122
» Latest member: AnthonyLFN
» Forum threads: 967
» Forum posts: 2,657

Full Statistics

Online Users
There are currently 144 online users.
» 0 Member(s) | 143 Guest(s)
Bing

Latest Threads
10.2.3 Amplification
Forum: 4.10 Declarations
Last Post: hahn
06-05-2024, 08:57 AM
» Replies: 2
» Views: 289
A13-5-4 opposite operator...
Forum: AUTOSAR C++:2014 rules
Last Post: aromauld
26-04-2024, 03:34 PM
» Replies: 0
» Views: 210
C++17 [[fallthrough]]; at...
Forum: 6.6 Statements (C++)
Last Post: mshawa
22-04-2024, 06:29 PM
» Replies: 0
» Views: 210
cvalue and constant integ...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
19-04-2024, 04:53 PM
» Replies: 1
» Views: 275
Rule 6-2-3 and C++17 [[fa...
Forum: 6.6 Statements (C++)
Last Post: misra cpp
19-04-2024, 04:48 PM
» Replies: 1
» Views: 234
Rule 7.0.5 Example potent...
Forum: 4.7 Standard conversions
Last Post: misra cpp
12-04-2024, 01:54 PM
» Replies: 1
» Views: 216
Rule 0.2.4 non-compliant ...
Forum: 4.0 Language independent issues
Last Post: misra cpp
12-04-2024, 01:51 PM
» Replies: 1
» Views: 250
Further guidance on MISRA...
Forum: 8.10 The essential type model
Last Post: mshawa
09-04-2024, 02:29 PM
» Replies: 0
» Views: 176
MISRA AC SLSF:2023 AMD1
Forum: MISRA AC resources
Last Post: david ward
05-04-2024, 01:56 PM
» Replies: 0
» Views: 197
MISRA AC GMG:2023 release...
Forum: MISRA AC GMG discussions
Last Post: misra-ac
25-03-2024, 06:01 PM
» Replies: 2
» Views: 588