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

Username
  

Password
  





  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

Question 2.2 Dead code, 'operations' and casts
Posted by: ACHart - 21-10-2021, 01:39 PM - Forum: 8.2 Unused code - Replies (1)

Hi,

I have a question regarding the meaning of 'Dead Code' within MISRA-2012.  My question is, I believe, somewhat similar to this thread, but the contents of that thread appear to be missing such that I cannot determine what the exact question was, nor the answer.

My questions are:

1) What is an 'operation'?  'Dead code' is defined in terms of 'operations', but 'operation' is never defined in MISRA.

2) Does an addition/subtraction of a constant 0 to a value (either literally or by macro) count as dead code?  This sometimes happens in the context of register offsets where the first offset is 0.

Code:
#define BASE_ADDR 0x80000000u
#define CTRL_OFFSET 0x0u
uint32_t a = BASE_ADDR + 0x0u; // Dead addition?
uint32_t b = BASE_ADDR + CTRL_OFFSET; // Dead addition?

3) Does a cast of a value to it's own type count as dead code?
Code:
uint8_t a = (uint8_t)0u; // Dead cast? (Type of 0u is UTLR)
uint8_t b = (uint8_t)a; // Dead cast? (Type of a is uint8_t)


4) Does an explicit cast to a type for which implicit conversion is allowed count as dead code?
Code:
uint8_t a = (uint8_t)0; // Dead cast? (Type of 0 is STLR, but assignment is permitted by exception)
uint16_t b = (uint16_t)a; // Dead cast? (Conversion to wider type of same signedness is allowed implicitly)

Print this item

  for loop iterator being comapred to a variable of another type
Posted by: ZESS - 11-10-2021, 10:14 PM - Forum: 8.10 The essential type model - Replies (3)

So I had this bug where I was trying to compare my "for loop" iterator to a variable "var":

Code:
for (u_int8_t i=0; i<var; i++) ....


"var" was coded on 16 bits while "i" was coded on 8 bits , this led to an infinite loop as "i" could never reach "var".
I was wondering why this was not raised as a MISRA warning while compilation phase, I thought at first that I was disabling some rules but turned out I was not. I looked for a MISRA rule prohibiting this kind of implementation, but I could not find any.

I'm not sure if it's related to the tool I'm using or indeed there is no such rule that prevents comparing two variables with two different data types especially if they are used as break condition to loops.

Print this item

  Rule 17.4 and main
Posted by: hummelvario - 01-10-2021, 09:59 AM - Forum: 8.17 Functions - Replies (1)

Hello,
we are facing a conflict between armclang compiler warning and mandatory MISRA Rule.
The armclang compiler V6.16 seems to require "int main", but if we adhere to Rule 17.4 adding "return 0" at the end of main it is leading to a compiler warning.
(warning: 'return' will never be executed [-Wunreachable-code-return])

Who is having the higher priority here to comply with MISRA?
Is it required to deactivate / ignore the compiler warning at this point?

According to the C Standard, 5.1.2.2.3, paragraph 1 [ISO/IEC 9899:2011], "Reaching the } that terminates the main function returns a value of 0."
Is there another possibility to comply with the MISRA Rule 17.4?

Print this item

  Rule 14.3 and preprocessor constants
Posted by: hummelvario - 01-10-2021, 09:31 AM - Forum: 8.14 Control statement expressions - Replies (1)

Hi,


I have a question regarding a reported MISRA violation in our code, which isn't completely clear to me after reading the MISRA Guidelines.

Does the MISRA C:2012 Rule 14.3 (Controlling expressions shall not be invariant) also apply to predefined constants, which include function-lika macros?

Example:

Code:
#define ROUND_TO(type, val) ((type) (((val) < 0.0) ? ((val) - 0.5) : ((val) + 0.5)))

#define RMS_TO_AVERAGE  ROUND_TO(uint16_t, ((70.0) / (1.11)))


In this case the expression ((val) < 0.0) is invariant, but it is only once used initialising a constant (RMS_TO_AVERAGE).


Regards, Kevin

Print this item

  Rule8.9 applicability to const ?
Posted by: Soren_Kolbach_Hansen - 24-09-2021, 01:49 PM - Forum: 8.8 Declarations and defnitions - Replies (1)

Hello,

I have a question regarding rule 8.9.

We are currenly using static const instead of defines at the top of our files to manage implementation specific constants, however this is being flagged as a violation of rule8.9 if only used in one function, however as per the rationale of 8.9 this does not make all that much sense to us, is this really the intent of the rule?

Best regards

Soren

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,125
» Latest member: suzu
» Forum threads: 968
» Forum posts: 2,660

Full Statistics

Online Users
There are currently 151 online users.
» 0 Member(s) | 149 Guest(s)
Bing, Facebook

Latest Threads
A13-5-4 opposite operator...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
17-05-2024, 03:02 PM
» Replies: 1
» Views: 296
10.2.3 Amplification
Forum: 4.10 Declarations
Last Post: misra cpp
17-05-2024, 02:49 PM
» Replies: 3
» Views: 407
Application of Rule 15.0....
Forum: 4.15 Special member functions
Last Post: nehalpatel
14-05-2024, 06:19 PM
» Replies: 0
» Views: 42
C++17 [[fallthrough]]; at...
Forum: 6.6 Statements (C++)
Last Post: mshawa
22-04-2024, 06:29 PM
» Replies: 0
» Views: 273
cvalue and constant integ...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
19-04-2024, 04:53 PM
» Replies: 1
» Views: 321
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: 291
Rule 7.0.5 Example potent...
Forum: 4.7 Standard conversions
Last Post: misra cpp
12-04-2024, 01:54 PM
» Replies: 1
» Views: 273
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: 310
Further guidance on MISRA...
Forum: 8.10 The essential type model
Last Post: mshawa
09-04-2024, 02:29 PM
» Replies: 0
» Views: 257
MISRA AC SLSF:2023 AMD1
Forum: MISRA AC resources
Last Post: david ward
05-04-2024, 01:56 PM
» Replies: 0
» Views: 262