0

My library have below function lines:

int
lwip_stricmp(const char* str1, const char* str2)
{
  char c1, c2;

  do {
    c1 = *str1++;
    c2 = *str2++;
...

I have MISRAC2012-Rule-10.3 error like this:

Implict conversion of '*str1++' from essential type unsigned 8-bit to different or narrover essential type character

Implict conversion of '*str2++' from essential type unsigned 8-bit to different or narrover essential type character

How can I solve this error or how can I suppress this error ?

Lundin
  • 195,001
  • 40
  • 254
  • 396
hobik
  • 439
  • 4
  • 15
  • I don't see why this error is shown. `*str1++` is `const char` and `c1` is `char`. Whether it is signed or unsined depends on the implementation, but should be the same for both. How to suppress this message depends on the tool you use to perform the static code analysis and should be explained in the documentation. Often you can use special comments in the code to disable or enable certain checks. If you [edit] your question and add the name and version of your code analysis tool, someone might be able to give a specific answer. – Bodo Oct 01 '20 at 09:26
  • Why was this closed? The duplicate is an entirely different scenario. No promotion takes place in the code posted here. – Lundin Oct 01 '20 at 09:38

1 Answers1

1

If the code is as posted, then the tool is giving an incorrect diagnostic. No implicit promotions take place in the line c1 = *str1++; nor are there different essential types, both c1 and str are "essentially character type".

However, there is another (imo more serious) MISRA violation here. Combining ++ with other operators in the same expression is also strongly discouraged, particularly with other side effects, as in this case (see for example 13.3). Maybe this issue somehow fools your tool into producing the wrong diagnostic.

There's also rules about complex expressions and parenthesis etc. Make the code MISRA-C compliant like this:

c1 = *str1;
c2 = *str2;
str1++;
str2++;

If the tool is still complaining after the above fix, well then it's yet another bug in IAR's static analyser.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • Interestingly, I also get an error when using any operator with char. For example, I also get c1 essentialy character but is being used a numeric value error in the char c1_upc = c1 | 0x20 statement. – hobik Oct 01 '20 at 10:55
  • @hobik That warning is correct though, you shouldn't mix `char` and bitwise operators. `char` should only be used for strings, like you do in the question. – Lundin Oct 01 '20 at 12:28