Geek Answers Handbook

Literal zero instead of warning the MISRA pointer constant

I have this function:

void InitS(unsigned int &numS){ // this function returns a container for unsigned int // but it has a cast for int numS = props.numOfS(); if (numS > 0) { .. } }

It compiles, but gives me this MISRA warning:

MISRA-C ++ Rule 4-10-2 (required): Literal zero (0) should not be used as a pointer constant.

Now, if numShots was a "real" pointer, I could change 0 to NULL . But numShots is a link, and I have to treat it as it was int .

What does MISRA want and why?

+4
source share
3 answers

Since nums is an unsigned int , you need to compare with 0U , where the added "U" indicates that the literal is an unsigned int, compared to a signed int without.

These are constantly traps of my team. We do not understand why zero should be marked as unsigned.

In addition, you are not dealing with pointers. The signature of the unsigned int& function indicates that the variable will be passed by reference, not by a pointer. You will modify the original object, not the copy.

+4
source

Let me start by saying that I have no experience with MISRA-C ++, but a lot of MISRA-C.

MISRA-C has some concerns about type safety, which also apply to MISRA-C ++. One of these problems is that no implicit type advertising campaigns should occur. This is an urgent problem, implicit advertising campaigns are difficult to understand and lead to errors. Most C and C ++ programmers, surprisingly, do not even know how implicit promotions work. To educate programmers about this and protect against such errors, there are many MISRA rules regarding implicit type conversions / promotions.

  • One of these rules applies the suffix 'u' to all integer literals. The rationale for this rule is to find out that large literals close to the maximum int value are unsigned, for example, the literal type 0x80000000 not obvious to the reader. (I personally find this rule redundant and somewhat erroneous, since all implicit conversion threats are already covered by other rules.)

  • There is another rule indicating that the pointer checks that NULL must be explicit. You are not allowed to write if(ptr) , you must write if(ptr!=NULL) . Justification is the readability and type safety.

  • And, apparently, this rule indicates that pointers should not be compared with a null literal. I don’t understand the reasons for this, presumably they are afraid that you will mix pointers and simple integer variables. Apparently, they decided to deviate from the desire of Bjarna Straustrup to de-mystify null pointers in C ++. According to Stroustrup, NULL and 0 are always equivalent in C ++ (although C ++ 11 will have the nullptr keyword resolving this mess once and for all).

None of the above rules has anything to do with the code in your example! You are comparing a reference to a null literal, which is completely safe. The MISRA controller may complain about the lack of a 'u' suffix, but your checker did not.

My findings:

  • The MISRA-C ++ controller is faulty and gives the wrong errors.
  • The specific MISRA-C ++ rule against literal zero does not seem to make any sense. You must raise the deviation in your MISRA implementation against this rule and completely ignore the rule until someone can justify it.
+3
source

I could be wrong, I am not very seasoned in programming, and probably the answer is a bit late, but I think your MISRA-C controller thinks "it compares a link variable with a literal constant, so it should check for a NULL link", although this is not really true for references, you can try to assign the return value of the props.numOfS () function to a new variable, and then assign the variable referred to by numS on another line when comparing with the new variable.

i.e.

 void InitS(unsigned int &numS){ unsigned int foo; foo = props.numOfS(); //this function returns a container for unsigned int but it has a cast for int numS = foo; if (foo > 0) { .. } }

Check to see if it complains after that.

0
source

More articles:


All Articles