CERT C: Rule EXP37-C

Bad file access mode or status occurs when you use functions in the fopen or open group with invalid or incompatible file access modes, file creation flags, or file status flags as arguments. For instance, for the open function, examples of valid:

The defect can occur in the following situations.

The fix depends on the root cause of the defect. Often the result details show a sequence of events that led to the defect. You can implement the fix on any event in the sequence. If the result details do not show the event history, you can trace back using right-click options in the source code and see previous related events. See also Interpret Bug Finder Results in Polyspace Desktop User Interface.

See examples of fixes below.

If you do not want to fix the issue, add comments to your result or code to avoid another review. See:

#include <stdio.h>

void func(void) {
    FILE *file = fopen("data.txt", "rw"); //Noncompliant
    if(file!=NULL) {
        fputs("new data",file);
        fclose(file);
    }
}

In this example, the access mode rw is invalid. Because r indicates that you open the file for reading and w indicates that you create a new file for writing, the two access modes are incompatible.

One possible correction is to use the access mode corresponding to what you intend to do.

#include <stdio.h>

void func(void) {
    FILE *file = fopen("data.txt", "w");
    if(file!=NULL) {
        fputs("new data",file);
        fclose(file);
    }
}

Unreliable cast of function pointer occurs when a function pointer is cast to another function pointer that has different argument or return type.

This defect applies only if the code language for the project is C.

If you cast a function pointer to another function pointer with different argument or return type and then use the latter function pointer to call a function, the behavior is undefined.

Avoid a cast between two function pointers with mismatch in argument or return types.

See examples of fixes below.

If you do not want to fix the issue, add comments to your result or code to avoid another review. See:

#include <stdio.h>
#include <math.h>
#include <stdio.h>
#define PI 3.142
 
double Calculate_Sum(int (*fptr)(double))
{
    double  sum = 0.0;
    double  y;
	  
    for (int i = 0;  i <= 100;  i++)
    {
        y = (*fptr)(i*PI/100);
        sum += y;
    }
    return sum / 100;
}
 
int main(void)
{
    double  (*fp)(double);      
    double  sum;
 
    fp = sin;
    sum = Calculate_Sum(fp);  //Noncompliant
    /* Defect: fp implicitly cast to int(*) (double) */

    printf("sum(sin): %f\n", sum);
    return 0;
}

The function pointer fp is declared as double (*)(double). However in passing it to function Calculate_Sum, fp is implicitly cast to int (*)(double).

One possible correction is to check that the function pointer in the definition of Calculate_Sum has the same argument and return type as fp. This step makes sure that fp is not implicitly cast to a different argument or return type.

#include <stdio.h>
#include <math.h>
#include <stdio.h>
# define PI 3.142
 
/*Fix: fptr has same argument and return type everywhere*/
double Calculate_Sum(double (*fptr)(double)) 
{
    double  sum = 0.0;
    double y;
	    
    for (int i = 0;  i <= 100;  i++)
    {
        y = (*fptr)(i*PI/100);
        sum += y;
    }
    return sum / 100;
}
 
int main(void)
{
    double  (*fp)(double);      
    double  sum;
 
    
    fp = sin;
    sum = Calculate_Sum(fp);
    printf("sum(sin): %f\n", sum);
 
    return 0;
}

Standard function call with incorrect arguments occurs when the arguments to certain standard functions do not meet the requirements for their use in the functions.

For instance, the arguments to these functions can be invalid in the following ways.

The fix depends on the root cause of the defect. Often the result details show a sequence of events that led to the defect. You can implement the fix on any event in the sequence. If the result details do not show the event history, you can trace back using right-click options in the source code and see previous related events. See also Interpret Bug Finder Results in Polyspace Desktop User Interface.

See examples of fixes below.

If you do not want to fix the issue, add comments to your result or code to avoid another review. See:

#include <string.h>
#include <stdlib.h>

enum {
    SIZE10 = 10,
    SIZE20 = 20
};

int func() {
    char* s = NULL;
    return strnlen(s, SIZE20); //Noncompliant
}

In this example, a NULL pointer is passed as strnlen argument instead of a NULL-terminated string.

Before running analysis on the code, specify a GNU compiler. See Compiler (-compiler).

Pass a NULL-terminated string as the first argument of strnlen.

#include <string.h>
#include <stdlib.h>

enum {
    SIZE10 = 10,
    SIZE20 = 20
};

int func() {
    char* s = "";
    return strnlen(s, SIZE20);
}

Unsupported complex arguments occurs when these functions are called with a complex argument:

Calling any of the preceding functions with a complex argument is undefined behavior in the C++ standard, which might lead to unexpected results. Because some mathematical functions support complex arguments while the functions in the preceding list do not, the unexpected results might be difficult to debug. Performing some of these mathematical operations on a complex number might not be mathematically sound, which indicates an issue in the underlying logic of your code.

Avoid calling the preceding functions with a complex input argument. To perform the preceding mathematical operations on a complex number, define alternative functions that support complex arguments.

#include <complex.h>
#include <tgmath.h>
typedef double complex cDouble;
cDouble Noncompliant (void)
{
    cDouble Z = 2.0 + 4.0 * I;
    cDouble result = log2 (Z); //Noncompliant
    return trunc(result);//Noncompliant
}

In this example, the function Noncompliant calculates the base two logarithm of a complex number, truncates the result, and returns it. The functions log2 and trunc do not support a complex argument. Polyspace^® flags these operations. To run this example, specify gnu6.x as the compiler. For instance, in the command line, use the option -compiler gnu6.x.

One possible correction is to define alternative functions that support complex numbers. For instance, while log2 does not support complex numbers, the function log does. Define a function complexLog2 that uses log to calculate the base two logarithm of a complex number. Similarly, trunc does not support complex numbers and the mathematical rule for truncating a complex number is not well-defined. Define a function complexTrunc that truncates a complex number by truncating its real and imaginary parts separately.

#include <complex.h>
#include <tgmath.h>
typedef double complex cDouble;

cDouble complexLog2(cDouble z) {
    return log (z) / log (2);  // Compliant
}

cDouble complexTrunc(cDouble z){
	return trunc(creal(z)) + I*trunc(cimag(z));  //Compliant
}
 
cDouble Compliant (void)
{
    cDouble Z = 2.0 + 4.0 * I;
    cDouble result = complexLog2 (Z); //Compliant
    return complexTrunc(result);//Compliant
}

Function declaration mismatch occurs when the prototype of a function does not match its definition. If a function lacks a prototype in the file where it is called, Polyspace deduces its prototype based on the signature of the call. If the deduced prototype does not match the definition of the function, Polyspace raises this defect. The prototype of a variadic function cannot be deduced from its function call. If you call a variadic function without specifying its prototype in the same file, Polyspace raises this defect.

When deducing the prototype of a function from a call to such a function, Polyspace makes these assumptions:

The checker does not flag this issue in a default Polyspace as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).

According to the C standard, function declaration mismatch might result in undefined behavior even though such code might compile successfully producing only warnings during compilation. Because code with this issue might compile successfully, function declaration mismatches might result in unexpected results that are difficult to diagnose.

When complete prototypes of the called functions are provided, the compiler tries to resolve any function declaration mismatches through implicit casting. If the compiler fails to resolve the mismatch, the compilation fails, which prevents unexpected behavior. To fix such compile errors, call the functions using argument types and numbers that match the function definition.

// file1.c
void foo(int iVar){
	//...
}
void bar(float fVar1, float fVar2){
	//...
}
void bar2(float fVar1){
	//...
}
void fubar(const char* str,...){
	//...
}
void foo2(char cVar){
	//...
}
void call_variadic(){
	fubar("String");
}

//file2.c
void bar2(float);
void foo2(int);
void call_funcs(){
	int iTemp;
	float fTemp;
	foo();//Noncompliant
	bar(fTemp,fTemp);//Noncompliant
	fubar("String"); //Noncompliant	
	bar2(iTemp);//Compliant
	foo2(iTemp); //Noncompliant
}

In this example, the functions foo, foo2, bar, bar2, and fubar are defined in the file file1.c. These functions are then called in the file file2.c.

The fix for this defect is to declare complete prototypes for the called functions in all compilation modules. It is a best practice to combine the function prototype declarations in a header file, and then include it in files where the functions are called. In this case, resolve the flagged issues by including such a header file prototype.h in file2.c. Once a correct prototype is declared, the call foo() in file2.c causes a compilation failure because the compiler cannot resolve the mismatch between the call and the declared prototype. Call foo with an int to resolve the compilation failure.

// file1.c
void foo(int iVar){
	//...
}
void bar(float fVar1, float fVar2){
	//...
}
void bar2(float fVar1){
	//...
}
void fubar(const char* str,...){
	//...
}
void foo2(char cVar){
	//...
}
void call_variadic(){
	fubar("String");
}

//prototypes.h
void foo(int iVar);
void bar(float fVar1, float fVar2);
void fubar(const char* str,...);
void bar2(float);
void foo2(char);
void call_variadic(void);
void call_funcs(void);

//file2.c
#include"prototype.h"
void call_funcs(){
	int iTemp;
	float fTemp;
	//foo(); This call results in compile failure
	foo(iTemp);//Compliant
	bar(fTemp,fTemp);//Compliant
	fubar("String"); //Compliant	
	bar2(iTemp);//Compliant
	foo2('a'); //Compliant
}

Incompatible argument occurs when an external function is called by using an argument that is not compatible with the prototype. The compatibility of types might depend on the set of hardware and software that you use. For instance, consider this code:

extern long foo(int);

long bar(long i) {
    return foo(i); //Noncompliant: calls foo(int) with a long              
}

Calling external functions with arguments that are incompatible with the parameter is undefined behavior. Depending on your environment, the code might compile but behave in an unexpected way.

When calling external functions, use argument types that are smaller or equal in size compared to the parameter type defined in the prototype. Check the sizes of various integer types in your environment to determine compatibility of argument and parameter types.

extern long foo1(int);
extern long foo2(long);
void bar(){
	int varI;
	long varL;
	foo1(varL);//Noncompliant
	foo2(varI);//Compliant
}

In this example, the external function foo1 is called with a long argument, while the prototype specifies the parameter as an int. In x86 architecture, the size of long is larger than the size of int. The call foo1(varL) might result in undefined behavior. Polyspace flags the call. The call foo2(varI) uses an int argument while the parameter is specified as a long. This type of mismatch is compliant with this rule because the size of int is not larger than the size of long.

To run this example in Polyspace, use these options:

See Target processor type (-target).

To fix this issue, cast the argument of foo1 explicitly so that argument type and parameter type matches.

extern long foo1(int);
extern long foo2(long);
void bar(){
	int varI;
	long varL;
	foo1((int)varL);//Compliant
	foo2(varI);//Compliant
}