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

Username
  

Password
  





  Rule 13.5
Posted by: TomDK - 17-11-2023, 01:48 PM - Forum: 8.13 Side effects - Replies (2)

In our first project with MISRA we have a question.
 
The couple of “issues” with MISRA 2012 rule 13.5:
 
Variables:
volatile uint8_t bMakeAlarm; (from interrupt)
uint8_t bRelay;
uint8_t bCountSW2High;
uint8_t bPlayerPlaying;
 
Info: SW2 = (PORTA.IN & (uint8_t)PIN5_bm) is a “register” (CPU)
 
Original if statement
 
if (SW2 == 0U || bMakeAlarm != 0U || bRelay != 0U || bCountSW2High != 0U || bPlayerPlaying != 0U)
{
  do_something;
}
 
This makes the message 13.5 because bMakeAlarm is volatile.
 
If I change it a little bit to (removing the volatile):
 
if (SW2 == 0U || bRelay != 0U || bCountSW2High != 0U || bPlayerPlaying != 0U)
{
  b100mSCount = 0U;
}
 
This complies with MISRA. However if change it to this which is normally basically the same:
 
if (bRelay != 0U || SW2 == 0U || bCountSW2High != 0U || bPlayerPlaying != 0U)
{
  b100mSCount = 0U;
}
 
This not comply with 13.5, why?
 
Like in recommendations for the rule 13.5 this will work:
 
SW2hold = SW2;
bMakeAlarmHold = bMakeAlarm;
   
if (bRelay != 0U || SW2hold == 0U || bMakeAlarmHold != 0U || bCountSW2High != 0U || bPlayerPlaying != 0U)
{
  b100mSCount = 0U;
}
 
What is the best solution?
But not super readable and could lead to faults if you do not remember that the xxxHold is just a temp. Any other good work-a-rounds?

Thanks  Smile

Print this item

  MISRA AC GMG:2023 rule 011 - Erratum
Posted by: misra-ac - 14-11-2023, 02:41 PM - Forum: MISRA AC GMG discussions - No Replies

Please note the following error in rule MISRA AC GMG 011 of some impressions of MISRA AC GMG:2023:

The text

     Only the four relational operators: ">", "<", ">=" and "=" may be used for comparing floating-point values

should instead read

     Only the four relational operators: ">", "<", ">=" and "<=" may be used for comparing floating-point values

Print this item

  MISRA C:2012 Rule 10.8 Question
Posted by: elfdream - 11-11-2023, 03:29 PM - Forum: 8.10 The essential type model - Replies (2)

The rule 10.8 states that "The value of a composite expression shall not be cast to a different essential type category or a wider essential type".

I understand that casting to a wider type will cause incompatibilities for different compilers where int have different width, but I don't understand why we cannot cast it to a different essential type category with the same or less width. 

In other words, the example

Code:
(uint32_t)(int32_t+int32_t)  /* Non-compliant */

is non-compliant, but the rationale behind this is feels unclear to me, as this code does not have inconsistency between compilers.

A possible explanation is that:
(1) despite the fact that writing like this will guarantee consistent behavior across compilers and architectures, 
(2) it easily misleads an inexperienced human programmer to interpret the computation inside the "()" to be carried out in uint32_t, which is of course not the case,
so this is banned.

I want to know whether this human readability is the rational behind the first clause of the rule. Thanks for looking into this matter in advance!

Print this item

  A4-5-1 with overloading operator<<
Posted by: Jakob Klein - 07-11-2023, 02:12 PM - Forum: AUTOSAR C++:2014 rules - Replies (2)

Hi

A4-5-1 states:

Quote:Expressions with type enum or enum class shall not be used as operands to built-in and overloaded operators other than the subscript operator [ ], the assignment operator =, the equality operators == and ! =, the unary & operator, and the relational operators <, <=, >, >=.
My understanding of the rule is that confusion should be avoided when using the underlying type arithmetically.
My use-case is overloading operator<< for convenient logging and printing of an unscoped enum:


Code:
inline std::ostream& operator<<(std::ostream& os, MyEnum const& enum_value)
{
    switch (enum_value)
    {
        case MyEnum_Unknown:
        {
            return os << "Unknown";
        }
        case MyEnum_Val1:
        {
            return os << "Descriptive message... (MyEnum_Val1)";
        }//...
     }
}

Usage, where the warning is shown:
Code:
LOG_WARNING << "Could not perform action with " << enum_value;



So as long as the enum is not used in arithmetic context ie. bitwise operations (the enum is the left-hand operand) but with the streeam insertion operator I can not follow the rationale of the rule. Is this an oversight in the rule or is there a more specific reason behind this?

Print this item

  A3-9-1 exception for using "unsigned char" for storage?
Posted by: cgpzs - 30-10-2023, 12:52 PM - Forum: AUTOSAR C++:2014 rules - Replies (2)

A3-9-1 forbids the use of char (and a recent question clarifies that it's intended for signed/unsigned char).

However, how can we create storage in that case, since we don't have std::byte until C++17? We could use `std::uint8_t`, but that's not the type that is used in the Standard, and could potentially not be identical to "unsigned char" depending on platform.

Example use case:

Code:
alignas(T) unsigned char data[sizeof(T)];
T* p = new (data) T();

Print this item

  C, Assembler and MISRA
Posted by: Errol - 25-10-2023, 08:56 AM - Forum: General Questions - Replies (1)

Understanding that assembler code has to be documented and isolated (Directives 4.2 & 4.3 ), are there any limits to how much assembly code there is in a project? Could you have have a project that is mostly assembly with only C wrappers and yet still claim MISRA compliance?

Print this item

  14.3 and enum constants in macro expansion
Posted by: Timofei - 19-10-2023, 07:30 AM - Forum: 8.14 Control statement expressions - Replies (1)

Hi,

We have a configuration macro with a value being an enum constant. We use that macro in an if-statement, and it violates the rule 14.3.

Code:
enum my_enum {
    MY_ENUM
};

#define CONF_MACRO MY_ENUM

if (CONF_MACRO == MY_ENUM) {...}


Note that in the case of enum constants we cannot convert the if-statement to a preprocessor #if-statement since the values of enum constants are not known at the preprocessing step. How can we solve this issue?

Print this item

  A6-4-1 What is the definition of a "case-clause"?
Posted by: cgpzs - 11-10-2023, 07:17 AM - Forum: AUTOSAR C++:2014 rules - Replies (1)

Hi!

Rule A6-4-1 says:

Rule A6-4-1 (required, implementation, automated)
A switch statement shall have at least two case-clauses, distinct from
the default label.


What is the definition of a "case-clause"? Is it a "case-clause label", or a "case-clause block of code"?

Our static analyzer is warning about this code:


Code:
void foo(int i)
{
  switch(i)
  {
    case 3:
    case 7:
    case 12:
    case 25:
      doSomething();
      break;

    default:
      doSomethingElse();
      break;
  }
}


It warns because there is only one case "block of code" (doSomething), and it expects that there are at least 2 (distinct from default case). It then wants us to rewrite the code in a much less readable way, like:

Code:
if (i == 3 || i == 7 || i == 12 || i == 25)
{  
  doSomething();
}
else
{
  doSomethingElse()
}


Is our static analyzer correct in warning A6-4-1 in the above code?

Please note: A6-4-1 inherits from HIC++ HIC++ v4.0 [9]: 6.1.4, which is more explicit than AUTOSAR, claiming that "at least two case labels" are needed. There's a big difference between "label" and "block".

Furthermore, consider the documentation from Perforce about HIC++ 6.1.4:

https://www.perforce.com/resources/qac/h...statements

There, they claim that the following code is compliant (while not being compliant in AUTOSAR):


Code:
// @@+ Compliant: 2 case labels distinct from the default label +@@
switch (i)
{
  case 0:
  case 1:
    doSomething ();
    break;
  default:
    doSomethingElse ();
    break;
}

Why should AUTOSAR change the meaning of the HIC++ rule?

Thanks!

Print this item

  Rul1 14-7-1 and explicit class instantiation
Posted by: mstaron - 30-08-2023, 06:58 AM - Forum: 6.14 Templates (C++) - Replies (1)

Does this rule should detect functions in template classes, that have no instances, but the class is explicitly instantiated?
In this case member functions are instantiated accordingly to the C++ standard:

Quote:8 An explicit instantiation that names a class template specialization is also an explicit instantiation of the
same kind (declaration or definition) of each of its members (not including members inherited from base
classes and members that are templates) that has not been previously explicitly specialized in the translation
unit containing the explicit instantiation, except as described below. [ Note: In addition, it will typically be
an explicit instantiation of certain implementation-dependent data about the class. —end note ]
9 An explicit instantiation definition that names a class template specialization explicitly instantiates the class
template specialization and is an explicit instantiation definition of only those members that have been
defined at the point of instantiation.
but these functions are never used.

Example:

Code:
template <typename T>
class Temp {
    public:
    void f1(){}  // Compliant?
    void f2(){}  // Compliant?
};

template class Temp<int>;

Print this item

  A7-1-2: Is it really intented to mark also functions as constexpr?
Posted by: cgpzs - 28-08-2023, 09:37 AM - Forum: AUTOSAR C++:2014 rules - Replies (3)

Hi,

A7-1-2 says:
The constexpr specifier shall be used for values that can be determined at compile time.

So it only talks about "values", not "functions". However, in the example, it says the following code is not compliant, because the function Pow1 "can be" constexpr but is not marked as such:

Code:
std::int32_t Pow1(std::int32_t number)
{
    return (number * number);
}
void Fn()
{
    const std::int32_t threeSquare = Pow1(3); // Non-compliant, possible run-time evaluation
}

On the other hand, examples are not normative - the title of the rule is.

Therefore I ask: is rule A7-1-2 intended to mark every single function as constexpr if it _can_ be constexpr?

In my opinion, this has negative consequences. Constexpr-ness of a function should be a careful design decision, not something added blindly to comply with a static analysis tool. It limits the way an author can choose to implement a given function. Maybe today the function _can_ be constexpr, but tomorrow as an author I want to refactor the implementation to e.g. use more modern libraries from STL, which don't have constexpr support in C++14 (for example, a silly std::array::operator[] is not supported in constexpr functions). Changing the implementation would require removing constexpr and updating also all the clients (which could dramatically cascade into second-order functions and so on). Or the alternative would be to be locked into constexpr and have to resort to older-style code to implement it (e.g. use a C array instead of std::array), making the function ultimately less safe and violating other Autosar rules.

Thanks!

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,170
» Latest member: Huuu
» Forum threads: 996
» Forum posts: 2,750

Full Statistics

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

Latest Threads
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 341
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 305
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,428
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,838
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,453
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,666
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,221
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 399
MISRA 2023 Test Suite
Forum: General Questions
Last Post: grigdon
14-10-2024, 01:27 PM
» Replies: 0
» Views: 180
MISRA C:2023 ADD4
Forum: MISRA resources
Last Post: david ward
11-10-2024, 07:41 PM
» Replies: 0
» Views: 229