MISRA Discussion Forums
Portal

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

Username
  

Password
  

  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

  Rule 6-3-1: Does it also apply to "case" blocks?
Posted by: cgpzs - 24-08-2023, 12:05 PM - Forum: 6.6 Statements (C++) - Replies (1)

Consider this piece of code:

Code:
enum Foo
{
  a,
  b
};


void foo(Foo f)
{
  switch(f)
  {
    case a:
      std::cout << "a\n";
      break;
    case b:
      std::cout << "b\n";
      break;
  }

}

Is the above compliant with M6-3-1, or does one need to add braces also to the "case" blocks, e.g.:

Code:
case a:
{
  std::cout << "a\n";
  break;
}

Thanks!

Print this item

  MISRA C:2012 Rule 10.8 Clarification
Posted by: uk000032 - 14-08-2023, 01:58 PM - Forum: 8.10 The essential type model - Replies (1)

MISRA C:2012 Rule 10.8 states "The value of a composite expression shall not be cast to a different essential type category or a wider essential type".

One example of a violation given is:

( uint32_t ) ( u16a + u16b ) /* Non-compliant - cast to wider
                              * essential type */

But what about:

( uint32_t ) u16a + ( uint32_t ) u16b  /* Compliant? */

This kind of thing does get flagged by Polyspace 2022b as a violation of Rule 10.8, but am I correct in thinking that casting the variables before the compound operator is applied means that this not in fact a violation?

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,183
» Latest member: davtas
» Forum threads: 1,004
» Forum posts: 2,768

Full Statistics

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

Latest Threads
MISRA AC SLSF:2023 AMD3
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
13-01-2025, 10:58 AM
» Replies: 0
» Views: 45
MISRA AC SLSF:2023 AMD3
Forum: MISRA AC resources
Last Post: misra-ac
13-01-2025, 10:57 AM
» Replies: 0
» Views: 42
Rule 7.0.4 - exception fo...
Forum: 4.7 Standard conversions
Last Post: misra cpp
10-01-2025, 02:26 PM
» Replies: 4
» Views: 430
rule 7.0.5: clarification...
Forum: 4.7 Standard conversions
Last Post: misra cpp
10-01-2025, 02:11 PM
» Replies: 1
» Views: 108
Rule 7.0.6 - why the requ...
Forum: 4.7 Standard conversions
Last Post: misra cpp
10-01-2025, 01:24 PM
» Replies: 1
» Views: 66
Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: cgpzs
20-12-2024, 02:38 PM
» Replies: 2
» Views: 450
Rule 7.0.2: Unclear/quest...
Forum: 4.7 Standard conversions
Last Post: misra cpp
20-12-2024, 02:24 PM
» Replies: 1
» Views: 326
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: misra cpp
20-12-2024, 02:05 PM
» Replies: 1
» Views: 337
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 897
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 711