Main Content

AUTOSAR C++14 Rule M0-1-8

All functions with void return type shall have external side effect(s)

Since R2022a

Description

Rule Definition

All functions with void return type shall have external side effect(s).

Rationale

A function that has a void return type does not return anything. When such a function has no external side effects, it does not contribute to the output and consumes time. That these functions have no contribution to the output of the program might be contrary to developer expectation. Such a function might be unnecessary or indicate issues in the program design. Avoid such functions.

The MISRA C++:2008 standard considers these effects as external side effects:

  • Reading or writing in resources such as a file or a stream.

  • Changing the value of a nonlocal variable.

  • Changing the value of a reference type argument.

  • Using a volatile object.

  • Raising an exception.

Polyspace Implementation

Polyspace® flags the definition of a void type function if the function has no side effects.

Polyspace considers a function to have side effects if the function performs any of these tasks:

  • Calls an impure function other than itself.

  • Changes the value or dereferences a reference or pointer type argument.

  • Changes the value or deferences of a nonlocal variable.

  • Contains assembly instructions.

  • Accesses the this pointer of its parent class.

  • Raises an exception. Raising exceptions is considered as a side effect even if the function does not exit with an exception.

  • Writes into an absolute address by using a local pointer.

  • Accesses a volatile object, class member, or struct member.

  • Sets the value of a class or struct member.

This checker does not flag these entities:

  • Standard implementations of placement new and delete functions.

  • Constructors and destructors.

  • Virtual class member functions that are empty.

  • Lambda objects.

Troubleshooting

If you expect a rule violation but Polyspace does not report it, see Diagnose Why Coding Standard Violations Do Not Appear as Expected.

Examples

expand all

#include<cmath>
volatile int flag;
struct reg2 {
    struct reg1 {
      unsigned int U;
    } REG1;
    unsigned int* P;
  };

void init ( int refToInt )          // Noncompliant
{
	refToInt = 0;
}

void transform(double theta) //Noncompliant
{
	theta = sin(theta)/(1-cos(theta));
}
void foo(int val){ //Noncompliant
	if(val){
		foo(val--);
	}
}

void rd(void){ //Compliant
	if(flag==0){
		//...
	}
}
void read_reg(void){ //Compliant
	 reg2* reg = reinterpret_cast<reg2 *>((0x02008000));
	 reg->REG1.U = 0;
	 //...
}

In this example, Polyspace flags the void functions that have no side effects. For instance:

  • The function init() initializes a local variable. This function returns no value and has no additional side effects. Perhaps the function is intended to initialize a reference and you missed an & in the declaration. Polyspace flags the function.

  • The function transform() transforms a number to another number by calling the pure functions sin() and cos(). The function returns nothing and has no side effects. Perhaps the function is intended to return the transformed number and you missed a return statement. Polyspace flags the function.

  • The function foo() sets up a recursion but has no effect on the output. Perhaps the recursion is set up improperly. Polyspace flags the function.

  • The function rd() reads a volatile object flag. Polyspace does not raise a violation on this function.

  • The function read_reg() writes into the absolute address 0x02008000 by using the local pointer reg. Polyspace assumes that the function might have a side effects and does not raise a violation on it.

Check Information

Group: Language independent issues
Category: Required, Automated

Version History

Introduced in R2022a