06-08-2021, 11:39 AM
We would agree with your tool vendor, with caveats.
The essential type of the object v1 is definitely uint32_t.
The essential type of the constants v2 & v3 are uint8_t, as 2008 says constants are treated as though they were literals with the appropriate value.
The constexpr v4 is out of scope of 2008 (not in C++:2003)
The rationale can be illustrated with these examples (using your definitions for v1 and v2):
uint8_t v5 = v1; // narrowing violation would be expected here uint32 to unint8
uint8_t v6 = v2; // no violation here, because although v2 is of type uint32_t, it is known
// that it is a constant that can fit in the uint8_t
However we can see why you can argue that they should treated as uint32_t. This is an area that is under review by both MISRA C and C++
The essential type of the object v1 is definitely uint32_t.
The essential type of the constants v2 & v3 are uint8_t, as 2008 says constants are treated as though they were literals with the appropriate value.
The constexpr v4 is out of scope of 2008 (not in C++:2003)
The rationale can be illustrated with these examples (using your definitions for v1 and v2):
uint8_t v5 = v1; // narrowing violation would be expected here uint32 to unint8
uint8_t v6 = v2; // no violation here, because although v2 is of type uint32_t, it is known
// that it is a constant that can fit in the uint8_t
However we can see why you can argue that they should treated as uint32_t. This is an area that is under review by both MISRA C and C++
Posted by and on behalf of
the MISRA C++ Working Group
the MISRA C++ Working Group