<![CDATA[MISRA Discussion Forums - 6.5 Expressions (C++)]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 15:13:56 +0000 MyBB <![CDATA[M5-0-4 switch over unscoped enum without fixed underlying type]]> https://forum.misra.org.uk/showthread.php?tid=1785 Wed, 16 Sep 2026 11:08:53 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1785
Our static analyzer is flagging this code:

Code:
// third_party.h
typedef enum
{
  FOO_A,
  FOO_B
} Foo;

// main.cpp
#include <third_party.h>

int get(Foo x)
{
  switch(x)            // Non-compliant with M5-0-4 ?
  {
    case FOO_A:        // Non-compliant with M5-0-4 ?
      return 123;
    case FOO_B:        // Non-compliant with M5-0-4 ?
      return 321;
  }
  return -1;
}

The rationale from the supplier is:
  • "Foo" is an unscoped enum without fixed underlying type.
  • Thus, its underlying type is implementation-defined.
  • On this implementation, the actual type is "unsigned int".
  • The line with "switch(x)" performs an integral promotion of "x" to "int", thus changing the signedness from "unsigned int" to "int".
  • Similarly, the "case FOO_*" lines also perform an integral promotion to "int".
  • This change in signedness is a violation of M5-0-4.

We argue however that the code is perfectly safe and idiomatic, the Standard guarantees that the conversion is made to an integer able to hold all the values of the enumerator, so it's impossible for data loss to occur.

What is your opinion, is M5-0-4 truly applicable in this case?

Thanks!]]>
Our static analyzer is flagging this code:

Code:
// third_party.h
typedef enum
{
  FOO_A,
  FOO_B
} Foo;

// main.cpp
#include <third_party.h>

int get(Foo x)
{
  switch(x)            // Non-compliant with M5-0-4 ?
  {
    case FOO_A:        // Non-compliant with M5-0-4 ?
      return 123;
    case FOO_B:        // Non-compliant with M5-0-4 ?
      return 321;
  }
  return -1;
}

The rationale from the supplier is:
  • "Foo" is an unscoped enum without fixed underlying type.
  • Thus, its underlying type is implementation-defined.
  • On this implementation, the actual type is "unsigned int".
  • The line with "switch(x)" performs an integral promotion of "x" to "int", thus changing the signedness from "unsigned int" to "int".
  • Similarly, the "case FOO_*" lines also perform an integral promotion to "int".
  • This change in signedness is a violation of M5-0-4.

We argue however that the code is perfectly safe and idiomatic, the Standard guarantees that the conversion is made to an integer able to hold all the values of the enumerator, so it's impossible for data loss to occur.

What is your opinion, is M5-0-4 truly applicable in this case?

Thanks!]]> <![CDATA[M5-0-20 clarification]]> https://forum.misra.org.uk/showthread.php?tid=1640 Wed, 25 Jan 2023 16:37:10 +0000 rt1980]]> https://forum.misra.org.uk/showthread.php?tid=1640
Rule 5-0-20 states that "Non-constant operands to a binary bitwise operator shall have the same underlying type." seems to make sense but my colleagues and I are bit unsure why the non-constant qualifier? 

Consider the following example. It's not clear to us why the first should be allowed if the second is not.
Code:
int foo(int i) {
  const unsigned char mask = ~(0x10);
  return i ^ mask; // compliant: mask is const
}

int foo(int i) {
  unsigned char mask = ~(0x10);
  return i ^ mask; // non-compliant: mask is not const and a different type than i
}


Thanks for your help!
Rafe]]>
Rule 5-0-20 states that "Non-constant operands to a binary bitwise operator shall have the same underlying type." seems to make sense but my colleagues and I are bit unsure why the non-constant qualifier? 

Consider the following example. It's not clear to us why the first should be allowed if the second is not.
Code:
int foo(int i) {
  const unsigned char mask = ~(0x10);
  return i ^ mask; // compliant: mask is const
}

int foo(int i) {
  unsigned char mask = ~(0x10);
  return i ^ mask; // non-compliant: mask is not const and a different type than i
}


Thanks for your help!
Rafe]]> <![CDATA[Why example in Rule 5-0-13 is non-compliant]]> https://forum.misra.org.uk/showthread.php?tid=1629 Wed, 27 Jul 2022 19:13:35 +0000 kafka]]> https://forum.misra.org.uk/showthread.php?tid=1629 <![CDATA[5-2-10 with non-arithmetic operators]]> https://forum.misra.org.uk/showthread.php?tid=1611 Tue, 05 Apr 2022 12:34:42 +0000 Tobias Loose]]> https://forum.misra.org.uk/showthread.php?tid=1611
The rule states 


Quote:The increment (++) and decrement (--) operators should not be mixed with other operators in an expression.


The code checker we employ also flags the usage of these operators in expressions that contain member-access operators, subscript operators, and the like.

The rationale and example appear to focus on other arithmetic operators, which makes sense.

Is this an oversight in the rule formulation (missing "arithmetic"), or is the following intentionally non-compliant with 5-2-10?

Code:
void foo()
{
    struct A { int b; };

    A a{0};

    a.b++; // Non-compliant

    int c[3] = {1, 2, 3};

    c[2]++; // Non-compliant

    A* const a_ptr = &a;

    a_ptr->b++; // Non-compliant
}

Thanks!]]>
The rule states 


Quote:The increment (++) and decrement (--) operators should not be mixed with other operators in an expression.


The code checker we employ also flags the usage of these operators in expressions that contain member-access operators, subscript operators, and the like.

The rationale and example appear to focus on other arithmetic operators, which makes sense.

Is this an oversight in the rule formulation (missing "arithmetic"), or is the following intentionally non-compliant with 5-2-10?

Code:
void foo()
{
    struct A { int b; };

    A a{0};

    a.b++; // Non-compliant

    int c[3] = {1, 2, 3};

    c[2]++; // Non-compliant

    A* const a_ptr = &a;

    a_ptr->b++; // Non-compliant
}

Thanks!]]> <![CDATA[Rule 5-0-6 about underlying type of boolean bit field]]> https://forum.misra.org.uk/showthread.php?tid=1610 Fri, 01 Apr 2022 09:08:50 +0000 zhaohui]]> https://forum.misra.org.uk/showthread.php?tid=1610 Quote:Rule 5–0–6 (Required) An implicit integral or floating-point conversion shall not reduce the size of the underlying type.
Refer to the Bit-field operands part of determination of the underlying type of an expression, 
Quote:Bit-field objects have an underlying type equivalent to an integral type of a size determined by their width. For example, a bit-field with width n, will have the same underlying type as a fundamental type with the same sign and width (if one exists).

However, for one bit field, there's no any fundamental type with only one bit.
So what exactly are bitAs' and bitBs' underlying types? Please help to clarify, thanks.

Code:
struct
{
    bool bitA : 1;
    int  bitB : 1;
} boolbitfield;

int main()
{
    bool b = boolbitfield.bitA; // compliant or non-compliant?
}
]]> Quote:Rule 5–0–6 (Required) An implicit integral or floating-point conversion shall not reduce the size of the underlying type.
Refer to the Bit-field operands part of determination of the underlying type of an expression, 
Quote:Bit-field objects have an underlying type equivalent to an integral type of a size determined by their width. For example, a bit-field with width n, will have the same underlying type as a fundamental type with the same sign and width (if one exists).

However, for one bit field, there's no any fundamental type with only one bit.
So what exactly are bitAs' and bitBs' underlying types? Please help to clarify, thanks.

Code:
struct
{
    bool bitA : 1;
    int  bitB : 1;
} boolbitfield;

int main()
{
    bool b = boolbitfield.bitA; // compliant or non-compliant?
}
]]> <![CDATA[M5-0-15 + range-based for loops]]> https://forum.misra.org.uk/showthread.php?tid=1599 Tue, 15 Feb 2022 12:25:13 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1599
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!]]>
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!]]> <![CDATA[5-2-12 - Does the rule apply for braced-init-list arg to initializer_list parameter?]]> https://forum.misra.org.uk/showthread.php?tid=1591 Wed, 24 Nov 2021 15:23:30 +0000 DavidFriberg]]> https://forum.misra.org.uk/showthread.php?tid=1591 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!]]> 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!]]> <![CDATA[Essential types of constant variables]]> https://forum.misra.org.uk/showthread.php?tid=1578 Fri, 30 Jul 2021 22:27:18 +0000 LordMordac]]> https://forum.misra.org.uk/showthread.php?tid=1578
Code:
uint32_t v1 = 1U;
const uint32_t v2 = 1U;
static const uint32_t v3 = 1U;
constexpr uint32_t v4 = 1U;

My interpretation of the spec is that all the identifiers (v1, v2, v3 and v4) have uint32_t essential type.

My tool vendor's interpretation is that v1 has a uint32_t essential type. While v2, v3 and v4 have a uint8_t essential type.  (I don't have any insight into their reasoning)

Clarification on this issue would be much appreciated.]]>
Code:
uint32_t v1 = 1U;
const uint32_t v2 = 1U;
static const uint32_t v3 = 1U;
constexpr uint32_t v4 = 1U;

My interpretation of the spec is that all the identifiers (v1, v2, v3 and v4) have uint32_t essential type.

My tool vendor's interpretation is that v1 has a uint32_t essential type. While v2, v3 and v4 have a uint8_t essential type.  (I don't have any insight into their reasoning)

Clarification on this issue would be much appreciated.]]> <![CDATA[Clarification for Rule 5-2-4]]> https://forum.misra.org.uk/showthread.php?tid=1500 Fri, 26 Jul 2019 14:06:07 +0000 abgs]]> https://forum.misra.org.uk/showthread.php?tid=1500
2. Does the phrase "explicit constructor call" in the rule mean "explicit-constructor call" (a call to a constructor declared with the 'explicit' specifier) or "explicit constructor-call" (an explicit call to a constructor, as opposed to an implicit conversion that uses a user-defined converting constructor)?

3. The rationale refers to dangers associated with casts that "do not invoke a converting constructor", however a "converting constructor" is a constructor that was *not* declared with the 'explicit' specifier. Was this intended to refer to casts that *do* invoke a converting constructor [as opposed to an explicit constructor]?

4. In the first compliant example with the expression 'A(10)' the declared constructor 'A(int32_t)' is declared with the explicit specifier. Would the 'A(10)' example be non-compliant if this constructor declaration lacked the 'explicit' specifier?

5. In later versions of the C++ standard, "Explicit type conversion (functional notation)" includes a type name followed by a braced list, e.g. 'X{5}', which may be used for aggregate initialization for 'struct X { int32_t a; };'. Is it within the original spirit of the rule to include this sytnax?]]>
2. Does the phrase "explicit constructor call" in the rule mean "explicit-constructor call" (a call to a constructor declared with the 'explicit' specifier) or "explicit constructor-call" (an explicit call to a constructor, as opposed to an implicit conversion that uses a user-defined converting constructor)?

3. The rationale refers to dangers associated with casts that "do not invoke a converting constructor", however a "converting constructor" is a constructor that was *not* declared with the 'explicit' specifier. Was this intended to refer to casts that *do* invoke a converting constructor [as opposed to an explicit constructor]?

4. In the first compliant example with the expression 'A(10)' the declared constructor 'A(int32_t)' is declared with the explicit specifier. Would the 'A(10)' example be non-compliant if this constructor declaration lacked the 'explicit' specifier?

5. In later versions of the C++ standard, "Explicit type conversion (functional notation)" includes a type name followed by a braced list, e.g. 'X{5}', which may be used for aggregate initialization for 'struct X { int32_t a; };'. Is it within the original spirit of the rule to include this sytnax?]]> <![CDATA[Underlying type's implicit conversion of the shift operators]]> https://forum.misra.org.uk/showthread.php?tid=1497 Fri, 19 Jul 2019 11:49:26 +0000 chill]]> https://forum.misra.org.uk/showthread.php?tid=1497
Quote:The underlying type of the result is the underlying type of the shift-expression.

[code]
int8_t i8;
uint8_t u8;
uint32_t u32;
int32_t i32;

u32 + i8; // i8 -> u32
u32 += i8; // i8 -> u32

u32 ]]>
Quote:The underlying type of the result is the underlying type of the shift-expression.

[code]
int8_t i8;
uint8_t u8;
uint32_t u32;
int32_t i32;

u32 + i8; // i8 -> u32
u32 += i8; // i8 -> u32

u32 ]]> <![CDATA[About Rule 5-0-15 and the size of the array]]> https://forum.misra.org.uk/showthread.php?tid=1481 Mon, 25 Mar 2019 17:32:17 +0000 Sebastien.Ashby@nxp]]> https://forum.misra.org.uk/showthread.php?tid=1481 I have a question about Rule 5-0-15: "Array indexing shall be the only for of pointer arithmetic".

Is the rule satisfied if the code referencing the array element has no knowledge of the dimensions of the array object at compile/link time?

For example, in the case where the argument passed to parameter "p2" of "my_fn" is an array whose size is defined at runtime?

Code:
void my_fn ( uint8_t * p1, uint8_t p2[ ] )
{
   uint8_t index = 0;
   uint8_t * p3;
   uint8_t * p4;
   *p1 = 0;
   ++index;
   index = index + 5;
   p1      = p1 + 5;   // Non-compliant – pointer increment
   p1[ 5 ] = 0;        // Non-compliant – p1 was not declared as array
   p3      = &p1[ 5 ]; // Non-compliant – p1 was not declared as array

   p2[ 0 ]     = 0;
   p2[ index ] = 0;        // Compliant
   p4          = &p2[ 5 ]; // Compliant
}
uint8_t a1[ 16 ];
uint8_t a2[ 16 ];

my_fn ( a1, a2 );
my_fn ( &a1[ 4 ], &a2[ 4 ] );
]]> I have a question about Rule 5-0-15: "Array indexing shall be the only for of pointer arithmetic".

Is the rule satisfied if the code referencing the array element has no knowledge of the dimensions of the array object at compile/link time?

For example, in the case where the argument passed to parameter "p2" of "my_fn" is an array whose size is defined at runtime?

Code:
void my_fn ( uint8_t * p1, uint8_t p2[ ] )
{
   uint8_t index = 0;
   uint8_t * p3;
   uint8_t * p4;
   *p1 = 0;
   ++index;
   index = index + 5;
   p1      = p1 + 5;   // Non-compliant – pointer increment
   p1[ 5 ] = 0;        // Non-compliant – p1 was not declared as array
   p3      = &p1[ 5 ]; // Non-compliant – p1 was not declared as array

   p2[ 0 ]     = 0;
   p2[ index ] = 0;        // Compliant
   p4          = &p2[ 5 ]; // Compliant
}
uint8_t a1[ 16 ];
uint8_t a2[ 16 ];

my_fn ( a1, a2 );
my_fn ( &a1[ 4 ], &a2[ 4 ] );
]]> <![CDATA[5-0-3: Meaning of "implicitly converted to a different underlying type"]]> https://forum.misra.org.uk/showthread.php?tid=1469 Mon, 11 Feb 2019 16:00:22 +0000 abgs]]> https://forum.misra.org.uk/showthread.php?tid=1469
The rationale goes on to say "an expression defined as a cvalue shall not undergo further implicit conversions".

In the expression 's64 = s32 + s32', the addition is a cvalue expression of underlying type int32_t. It is being assigned to an object of type int64_t. The C++ standard says (regarding the assignment operator): "If the left operand is not of class type, the [align=right] expression is implicitly converted to the cv-unqualified type of the left operand".

Does this "implicit conversion to the type of the left operand" qualify as causing the cvalue expression to be "implicitly converted to a different underlying type"?


In the expression 's64 == s32 + s32' the addition is a cvalue expression of underlying type int32_t. The C++ standard says (regarding the equality operator): "The usual arithmetic conversions are performed on operands of arithmetic or enumeration type", the result of which will be that "the
operand with the type of lesser integer conversion rank shall be converted to the type of the operand with greater rank". Additionally, MISRA C++ defines "underlying type conversions" and says they are "conceptual replacements for the usual arithmetic conversions". In this case, the "underlying type conversions" say: "... if both operands have integral type, the underlying type of the expression can be found using the following: ... the type of the result is that of the larger type". Whether the "usual arithmetic conversions" or the "underlying type conversions" are used, the result of the addition will be converted to int64_t.

Does the application of the usual arithmetic conversions and the ensuing implicit conversion to the larger type qualify as causing the cvalue expression to be "implicitly converted to a different underlying type"?


In the expression '0L == s32 + s32' (where long is int64_t and 0L is signed char as established here) does the implicit conversion from the promotion of the addition expression to int64_t qualify as causing the cvalue expression to be "implicitly converted to a different underlying type"?


Note that these examples intend to use s32 and 64 to avoid the operands to the addition operator undergoing sub-int promotion, i.e. s32 is 32-bit int and s64 is 64-bit long.]]>
The rationale goes on to say "an expression defined as a cvalue shall not undergo further implicit conversions".

In the expression 's64 = s32 + s32', the addition is a cvalue expression of underlying type int32_t. It is being assigned to an object of type int64_t. The C++ standard says (regarding the assignment operator): "If the left operand is not of class type, the [align=right] expression is implicitly converted to the cv-unqualified type of the left operand".

Does this "implicit conversion to the type of the left operand" qualify as causing the cvalue expression to be "implicitly converted to a different underlying type"?


In the expression 's64 == s32 + s32' the addition is a cvalue expression of underlying type int32_t. The C++ standard says (regarding the equality operator): "The usual arithmetic conversions are performed on operands of arithmetic or enumeration type", the result of which will be that "the
operand with the type of lesser integer conversion rank shall be converted to the type of the operand with greater rank". Additionally, MISRA C++ defines "underlying type conversions" and says they are "conceptual replacements for the usual arithmetic conversions". In this case, the "underlying type conversions" say: "... if both operands have integral type, the underlying type of the expression can be found using the following: ... the type of the result is that of the larger type". Whether the "usual arithmetic conversions" or the "underlying type conversions" are used, the result of the addition will be converted to int64_t.

Does the application of the usual arithmetic conversions and the ensuing implicit conversion to the larger type qualify as causing the cvalue expression to be "implicitly converted to a different underlying type"?


In the expression '0L == s32 + s32' (where long is int64_t and 0L is signed char as established here) does the implicit conversion from the promotion of the addition expression to int64_t qualify as causing the cvalue expression to be "implicitly converted to a different underlying type"?


Note that these examples intend to use s32 and 64 to avoid the operands to the addition operator undergoing sub-int promotion, i.e. s32 is 32-bit int and s64 is 64-bit long.]]> <![CDATA[Clarification for 5-0-20 (operands to a binary bitwise operator)]]> https://forum.misra.org.uk/showthread.php?tid=1468 Tue, 05 Feb 2019 15:52:50 +0000 udi]]> https://forum.misra.org.uk/showthread.php?tid=1468
Just to clarify what seems to be a mistake in the implementation of the static analysis tool I use:
According to the rationale, I believe that this rule does not refer to the shift operators, but only to following 6 operators:
&
|
^
&=
|=
^=
Am I right about this?

Thanks,
Udi.]]>
Just to clarify what seems to be a mistake in the implementation of the static analysis tool I use:
According to the rationale, I believe that this rule does not refer to the shift operators, but only to following 6 operators:
&
|
^
&=
|=
^=
Am I right about this?

Thanks,
Udi.]]> <![CDATA[Rule 5-2-6 and dynamicaly loading (.dll / .so)]]> https://forum.misra.org.uk/showthread.php?tid=1461 Tue, 18 Dec 2018 08:42:51 +0000 udi]]> https://forum.misra.org.uk/showthread.php?tid=1461 I believe that this rule should exempt a function retrieved with GetProcAddress / dlsym, as I believe this is not an undefined / unspecified behavior (or is it?).
It might make sense to add a requirement to review and document these cases.]]> I believe that this rule should exempt a function retrieved with GetProcAddress / dlsym, as I believe this is not an undefined / unspecified behavior (or is it?).
It might make sense to add a requirement to review and document these cases.]]> <![CDATA[5-2-7 and void pointer conversions]]> https://forum.misra.org.uk/showthread.php?tid=1437 Fri, 13 Jul 2018 02:32:55 +0000 rgamble]]> https://forum.misra.org.uk/showthread.php?tid=1437
Code:
void bar(int *ip, void *vp) {
    ip = static_cast(vp);
    vp = static_cast(ip);
}
]]>
Code:
void bar(int *ip, void *vp) {
    ip = static_cast(vp);
    vp = static_cast(ip);
}
]]>