<![CDATA[MISRA Discussion Forums - 6.10 Arithmetic Type Conversions]]>

<![CDATA[MISRA Discussion Forums - 6.10 Arithmetic Type Conversions]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 15:13:14 +0000 MyBB <![CDATA[Rule M10.1.1]]> https://forum.misra.org.uk/showthread.php?tid=1520 Thu, 05 Dec 2019 22:13:10 +0000 phdenis]]> https://forum.misra.org.uk/showthread.php?tid=1520
I've a problem when using the memset function, the error M10.1.1 is raised.
Error raised by the MISRA Tool used (RTRT):
line 12 row 30: Rule M10.1.1
Error: Implicit conversion of an integer expression to a different signedness is not allowed

Regarding the memset prototype,
void *memset (void *s, int c, size_t n);

The content of the test.h file is given see below:

Code:
#ifndef __TEST_H__

#define __TEST_H__

#define CST_UZERO   0U

#define CST_STRIPV4 16U /* IP: AAA.BBB.CCC.DDD */

typedef signed char SINT8_T;

typedef SINT8_T STRIPV4_T[CST_STRIPV4];

void MyFunc(void);

#endif /* __TEST_H__ */

The content of the test.c file is given see below:

Code:
#include "test.h"

#include 

void MyFunc(void)

{

    /* Local Variable(s) */

    STRIPV4_T NtpAddr1;

    /* Init */

    (void) memset(&NtpAddr1, CST_UZERO, CST_STRIPV4);

    return;

}

]]>
I've a problem when using the memset function, the error M10.1.1 is raised.
Error raised by the MISRA Tool used (RTRT):
line 12 row 30: Rule M10.1.1
Error: Implicit conversion of an integer expression to a different signedness is not allowed

Regarding the memset prototype,
void *memset (void *s, int c, size_t n);

The content of the test.h file is given see below:

Code:
#ifndef __TEST_H__

#define __TEST_H__

#define CST_UZERO   0U

#define CST_STRIPV4 16U /* IP: AAA.BBB.CCC.DDD */

typedef signed char SINT8_T;

typedef SINT8_T STRIPV4_T[CST_STRIPV4];

void MyFunc(void);

#endif /* __TEST_H__ */

The content of the test.c file is given see below:

Code:
#include "test.h"

#include 

void MyFunc(void)

{

    /* Local Variable(s) */

    STRIPV4_T NtpAddr1;

    /* Init */

    (void) memset(&NtpAddr1, CST_UZERO, CST_STRIPV4);

    return;

}

]]> <![CDATA[Rule 10.1]]> https://forum.misra.org.uk/showthread.php?tid=1440 Wed, 18 Jul 2018 09:30:20 +0000 phdenis]]> https://forum.misra.org.uk/showthread.php?tid=1440
I've an error 10.1 on the following C code:

Code:
#define MyConst 0x8A

Code:
#define MyConst 0x8A

My Code Review checker asks to add a U to the constant.

I'm quite surprised if it was a decimal value, I'll understand it but for an hexa, I don't really understand why ?

Another question is to know if a test set is present on the MISRA community to check the correct behaviour of the Code Review tool.

By advance thanks for your help.

B/R
Philippe]]> <![CDATA[Rule M16.10]]> https://forum.misra.org.uk/showthread.php?tid=1433 Wed, 04 Jul 2018 22:47:34 +0000 phdenis]]> https://forum.misra.org.uk/showthread.php?tid=1433
I'm using the Misra 2004:C rules for the 1st time (e.g. I'm a newbie) and I got several errors linked to the rule M16.10 when I'm using the strncpy function like that:

Code:
strncpy(MyStr1,MyConstStr, sizeof(MyConstStr);

I've fixed this error by adding a pointer to the code which is not used.

Code:
char *MyPtr;

MyPtr = strncpy(MyStr1,MyConstStr, sizeof(MyConstStr);

So my question is:
For the functions like strncpy, memset and others functions of the same style, do we need to fix the misra error or do we have to justify it plainly?

By advance, thanks for your help.]]>
I'm using the Misra 2004:C rules for the 1st time (e.g. I'm a newbie) and I got several errors linked to the rule M16.10 when I'm using the strncpy function like that:

Code:
strncpy(MyStr1,MyConstStr, sizeof(MyConstStr);

I've fixed this error by adding a pointer to the code which is not used.

Code:
char *MyPtr;

MyPtr = strncpy(MyStr1,MyConstStr, sizeof(MyConstStr);

So my question is:
For the functions like strncpy, memset and others functions of the same style, do we need to fix the misra error or do we have to justify it plainly?

By advance, thanks for your help.]]> <![CDATA[int vs long when sizes are identical and issue with int32_t (from rule 6.3) in rule 10.1 example]]> https://forum.misra.org.uk/showthread.php?tid=1364 Mon, 11 Sep 2017 18:14:58 +0000 abgs]]> https://forum.misra.org.uk/showthread.php?tid=1364

Code:
s32a = s16a + (int32_t)20000; /* compliant */

Rule 6.3 suggests this definition of int32_t:

Code:
typedef signed int int32_t;

The addition expression is a complex expression per 6.10.5.
The underlying type of s16a is int16_t.
The underlying type of (int32_t)20000 is int16_t because this is an integral constant expression and the "actual type" is int per 6.10.4:

Quote:If the actual type of the expression is (signed) int, the underlying type is defined to be the smallest signed integer type which is capable of representing its value.

Code:
s32a = s16a + (int32_t)20000; /* compliant */

Rule 6.3 suggests this definition of int32_t:

Code:
typedef signed int int32_t;

Quote:If the actual type of the expression is (signed) int, the underlying type is defined to be the smallest signed integer type which is capable of representing its value.

The underlying type of the sum is then int16_t (not int32_t as the example seems to assume).
int16_t is being assigned to int32_t which requires a conversion to change the underlying type, but this is a violation of rule 10.1 because the sum is a complex expression. Thus the example appears not to be compliant.

Is this example incorrect when int32_t is int?
It appears that the behavior would be different if int32_t were long because the integral constant expression rule would not apply, is this intentional? How should this potential difference in the definition be handled?
If int and long are the same size, does conversion between int and long violate rule 10.1 because it only allows conversions to wider types and not to types of the same size?]]> <![CDATA[Casting integer to floating point]]> https://forum.misra.org.uk/showthread.php?tid=1280 Tue, 04 Oct 2016 12:46:54 +0000 bobvanderputten]]> https://forum.misra.org.uk/showthread.php?tid=1280
int16_t int_torque_I_MUL;
float32_t f_temp1;
...
f_temp1 = (float32_t)(int_torque_I_MUL);
...
The above will generate:
MISRA-C:2012 R.10.1,R.10.3,R.10.4,R.10.5,R.11.1: Value is not of appropriate type. : (double and short)
But I don't understand why??
How can I cast a signed 16 bit integer to a double (float32_t )?]]>
int16_t int_torque_I_MUL;
float32_t f_temp1;
...
f_temp1 = (float32_t)(int_torque_I_MUL);
...
The above will generate:
MISRA-C:2012 R.10.1,R.10.3,R.10.4,R.10.5,R.11.1: Value is not of appropriate type. : (double and short)
But I don't understand why??
How can I cast a signed 16 bit integer to a double (float32_t )?]]> <![CDATA[How to fix Warnings 10.1 and 10.3]]> https://forum.misra.org.uk/showthread.php?tid=1186 Fri, 12 Jun 2015 18:58:51 +0000 chas]]> https://forum.misra.org.uk/showthread.php?tid=1186
unsigned int x = 0U;
unsigned int* px;

px = &x; /* 10.1 warning */
px = (unsigned int*)&x; /* 10.3 warning */]]>
unsigned int x = 0U;
unsigned int* px;

px = &x; /* 10.1 warning */
px = (unsigned int*)&x; /* 10.3 warning */]]> <![CDATA[Clarification on rule 10.6]]> https://forum.misra.org.uk/showthread.php?tid=1170 Tue, 24 Mar 2015 10:23:21 +0000 anuj1085]]> https://forum.misra.org.uk/showthread.php?tid=1170 <![CDATA[Typecasting from signed to unsigned and vis-verse]]> https://forum.misra.org.uk/showthread.php?tid=1091 Thu, 31 Jul 2014 10:47:24 +0000 deepabagalkot]]> https://forum.misra.org.uk/showthread.php?tid=1091
Please can anybody help me to understand whether Misra C rules support signed to unsigned and vis-verse data typecasting?

If there is requirement to do some manipulation on signed and unsigned values, then i think it is ok to type-caste. But the requirement given to us says that whenever there is typecasting happening from signed to unsigned and vis-verse, then such incident should be failed.

Thanks in advance,
Deepa]]>
Please can anybody help me to understand whether Misra C rules support signed to unsigned and vis-verse data typecasting?

If there is requirement to do some manipulation on signed and unsigned values, then i think it is ok to type-caste. But the requirement given to us says that whenever there is typecasting happening from signed to unsigned and vis-verse, then such incident should be failed.

Thanks in advance,
Deepa]]> <![CDATA[Rule 10.1 violation with casting]]> https://forum.misra.org.uk/showthread.php?tid=1025 Thu, 06 Feb 2014 12:29:55 +0000 Frasew]]> https://forum.misra.org.uk/showthread.php?tid=1025
my MISRA checker generates a MISRA violation 10.1 (The signedness of an integer type is converted implicitly.(signed -> unsigned)), although a casting is done.

My C code:

1: #include
2: typedef unsigned char U8;
...
w: U8 WriteProtect = (U8) true;
....
x: if(WriteProtect == (U8) false) {
....
y: WriteProtect = (U8) true;
....
z: }

The MISRA checker identifies line x and y as a rule 10.1 violation. Why is this a rule 10.1 violation although a casting is done? Interestingly the MISRA checker identifies line w as OK. Have anybody an idea what is my fault?

Is it generally impossible in MISRA to assign a signed var to an unsigned var?]]>
my MISRA checker generates a MISRA violation 10.1 (The signedness of an integer type is converted implicitly.(signed -> unsigned)), although a casting is done.

My C code:

1: #include
2: typedef unsigned char U8;
...
w: U8 WriteProtect = (U8) true;
....
x: if(WriteProtect == (U8) false) {
....
y: WriteProtect = (U8) true;
....
z: }

The MISRA checker identifies line x and y as a rule 10.1 violation. Why is this a rule 10.1 violation although a casting is done? Interestingly the MISRA checker identifies line w as OK. Have anybody an idea what is my fault?

Is it generally impossible in MISRA to assign a signed var to an unsigned var?]]> <![CDATA[Appendix B - mapping of rule 10.2]]> https://forum.misra.org.uk/showthread.php?tid=960 Tue, 23 Apr 2013 09:41:52 +0000 andream]]> https://forum.misra.org.uk/showthread.php?tid=960
"The unqualifed type of parameters passed to a function shall be compatible with the unqualified expected types defined in the function prototype".

Can you help me?]]>
"The unqualifed type of parameters passed to a function shall be compatible with the unqualified expected types defined in the function prototype".

Can you help me?]]> <![CDATA[10.1 Non-constant value to function]]> https://forum.misra.org.uk/showthread.php?tid=924 Mon, 26 Nov 2012 11:58:28 +0000 borth]]> https://forum.misra.org.uk/showthread.php?tid=924
i have a problem with these 10.1 Rule:

Code:
void foo_bar(uint32_t u32)      /* another function to do something */

void test_func(uint8_t u8)

{

   uint32_t u32Convert = (uint32_t)u8;

   ...

   foo_bar(u32Convert);      /*Error - Note 960 Violates MISRA 2004 Required Rule 10.1, Prohibited Implicit Conversion: Non-constant argument to function */

   ...

}

Code:
void foo_bar(uint32_t u32)      /* another function to do something */

void test_func(uint8_t u8)

{

   uint32_t u32Convert = (uint32_t)u8;

   ...

   foo_bar(u32Convert);      /*Error - Note 960 Violates MISRA 2004 Required Rule 10.1, Prohibited Implicit Conversion: Non-constant argument to function */

   ...

}

MISRA says that a expression, which is a function argument, shouldn't be converted to a underlying type.
But i took a 8 bit value, expand to 32bit and use this for the function. The type of u32Convert is uint32_t as it should be for the function argument of foo_bar.
Is it neccessary to know what foo_bar does with the value?

Thanks for your help!
Greetz,]]> <![CDATA[10.1 in a macro]]> https://forum.misra.org.uk/showthread.php?tid=917 Tue, 02 Oct 2012 06:34:59 +0000 borth]]> https://forum.misra.org.uk/showthread.php?tid=917

i got something like this:

[code]
#define X_MASK 0xFU
#define FOO(_a) ((_a) % 10U)
#define BAR(_b) (1U ]]>

i got something like this:

[code]
#define X_MASK 0xFU
#define FOO(_a) ((_a) % 10U)
#define BAR(_b) (1U ]]> <![CDATA[if statement with structure member and rule 10.1]]> https://forum.misra.org.uk/showthread.php?tid=863 Fri, 11 Nov 2011 11:10:36 +0000 rhbarnes]]> https://forum.misra.org.uk/showthread.php?tid=863 {
// do something...
}

uint16_t u16_rev1_min, u16_tmp;
u16_tmp = st_hardware_revs.u16_hw_rev1;
if (u16_tmp >= u16_rev1_min) /* this does not violates rule 10.1 */
{
// do something...
}
[/code]

My initial thought was due to the underlying 'int' type of the relational operator, however if this is the case then why does the second piece of code pass? Am I missing some implicit conversion applied to the strucuture reference?

Regards]]> {
// do something...
}

uint16_t u16_rev1_min, u16_tmp;
u16_tmp = st_hardware_revs.u16_hw_rev1;
if (u16_tmp >= u16_rev1_min) /* this does not violates rule 10.1 */
{
// do something...
}
[/code]

My initial thought was due to the underlying 'int' type of the relational operator, however if this is the case then why does the second piece of code pass? Am I missing some implicit conversion applied to the strucuture reference?

Regards]]> <![CDATA[if-statement with two checks with different data types]]> https://forum.misra.org.uk/showthread.php?tid=830 Tue, 07 Jun 2011 08:02:17 +0000 MaWu]]> https://forum.misra.org.uk/showthread.php?tid=830
I have a question about rule 10.1 and 10.2
Whenever I try to work with an if or while and use two comparions which are logically connected I get an MISRA issue when the two comparisons have different data types.
e.g. int16 and int32
Because the results of the two comparions is somehow boolean I would not expected to get:
The value of an expression implicitly converted to a different type.

Is it really an issue? I know I can cast both to the same data type but it looks strange.

Example:

Code:
t_int8 a = 3;

t_uint16 b = 7;

if ((a > 3) && (b > 5u))

{

   a++;  

}

]]>
I have a question about rule 10.1 and 10.2
Whenever I try to work with an if or while and use two comparions which are logically connected I get an MISRA issue when the two comparisons have different data types.
e.g. int16 and int32
Because the results of the two comparions is somehow boolean I would not expected to get:
The value of an expression implicitly converted to a different type.

Is it really an issue? I know I can cast both to the same data type but it looks strange.

Example:

Code:
t_int8 a = 3;

t_uint16 b = 7;

if ((a > 3) && (b > 5u))

{

   a++;  

}

]]> <![CDATA[Underlying type for integer constant expressions]]> https://forum.misra.org.uk/showthread.php?tid=822 Tue, 12 Apr 2011 09:30:42 +0000 Mats Fors]]> https://forum.misra.org.uk/showthread.php?tid=822 uint8_t d = ((uint8_t) 0x1U) | ((uint8_t) 0x2U);
should, according to the MISRA-C guidelines, generate an error for rule 10.1. The initializer, i.e. the integer constant expression, has the underlying type of uint8_t, but that type is overruled by the explicit rule for integer constant expressions in 6.10.4 that says that the signedness/unsignedness of the underlying type should be taken from the actual type of the integer constant expression, but only if it is signed or unsigned int. In this case it is signed int. Giving the rule 10.1 breakage. Is this really the intention of the MISRA-C guidelines for integer constant expressions?]]> uint8_t d = ((uint8_t) 0x1U) | ((uint8_t) 0x2U);
should, according to the MISRA-C guidelines, generate an error for rule 10.1. The initializer, i.e. the integer constant expression, has the underlying type of uint8_t, but that type is overruled by the explicit rule for integer constant expressions in 6.10.4 that says that the signedness/unsignedness of the underlying type should be taken from the actual type of the integer constant expression, but only if it is signed or unsigned int. In this case it is signed int. Giving the rule 10.1 breakage. Is this really the intention of the MISRA-C guidelines for integer constant expressions?]]>