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

Username
  

Password
  





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

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 - No Replies

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 (2)

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 - No Replies

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++) - No Replies

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

Search Forums

(Advanced Search)

Forum Statistics
» Members: 5,711
» Latest member: lodewijk.bergmans
» Forum threads: 885
» Forum posts: 2,442

Full Statistics

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

Latest Threads
MISRA C:2012 Amendment 1
Forum: MISRA resources
Last Post: Vijayanand
Yesterday, 04:37 PM
» Replies: 1
» Views: 10,012
9-3-3 and interfaces enfo...
Forum: 6.9 Classes (C++)
Last Post: cgpzs
14-01-2022, 07:51 AM
» Replies: 2
» Views: 136
Side effects in floating ...
Forum: 8.13 Side effects
Last Post: gdavis
13-01-2022, 09:27 PM
» Replies: 0
» Views: 30
Rule 13.4 For statement o...
Forum: 8.13 Side effects
Last Post: misra-c
13-01-2022, 02:14 PM
» Replies: 1
» Views: 91
A20-8-6
Forum: AUTOSAR C++:2014 rules
Last Post: martin.m.dowie
12-01-2022, 09:35 AM
» Replies: 0
» Views: 47
A3-1-5 - Rationale and ex...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
11-01-2022, 11:32 AM
» Replies: 3
» Views: 395
A5-0-4 - Does the rule ap...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
11-01-2022, 11:27 AM
» Replies: 3
» Views: 410
Rule A13-2-3 - Relational...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
11-01-2022, 11:23 AM
» Replies: 1
» Views: 119
6-5-2 and 6-5-4 on while ...
Forum: 6.6 Statements (C++)
Last Post: misra cpp
11-01-2022, 10:55 AM
» Replies: 5
» Views: 487
R4-5-1 Alternative tokens
Forum: 6.4 Standard conversions (C++)
Last Post: misra cpp
11-01-2022, 10:47 AM
» Replies: 3
» Views: 445