ISO/IEC TS 17961 [funcdecl]

The issue occurs when external identifiers are not distinct.

External identifiers are ones declared with global scope or storage class extern.

Polyspace considers two names as distinct if there is a difference between their first 31 characters. If the difference between two names occurs only beyond the first 31 characters, they can be easily mistaken for each other. The readability of the code is reduced. For C90, the difference must occur between the first 6 characters. To use the C90 rules checking, use the value c90 for the option C standard version (-c-version).

int engine_temperature_raw;
int engine_temperature_scaled;   /* Non-compliant */					
int engin2_temperature;          /* Compliant */	

In this example, the identifier engine_temperature_scaled has the same first six characters as a previous identifier, engine_temperature_raw.

int engine_exhaust_gas_temperature_raw;
int engine_exhaust_gas_temperature_scaled; /* Non-compliant */					

int eng_exhaust_gas_temp_raw;
int eng_exhaust_gas_temp_scaled;           /* Compliant */						

In this example, the identifier engine_exhaust_gas_temperature_scaled has the same first 31 characters as a previous identifier, engine_exhaust_gas_temperature_raw.

/* file1.c */
int abc = 0; //Noncompliant

/* file2.c */
int ABC = 0; 

In this example, the implementation supports 6 significant case-insensitive characters in external identifiers. The identifiers in the two translation are different but are not distinct in their significant characters.

Declaration mismatch occurs when a function or variable declaration does not match other instances of the function or variable.

When a mismatch occurs between two variable declarations in different compilation units, a typical linker follows an algorithm to pick one declaration for the variable. If you expect a variable declaration that is different from the one chosen by the linker, you can see unexpected results when the variable is used.

A similar issue can occur with mismatch in function declarations.

The fix depends on the type of declaration mismatch. If both declarations indeed refer to the same object, use the same declaration. If the declarations refer to different objects, change the names of the one of the variables. If you change a variable name, remember to make the change in all places that use the variable.

Sometimes, declaration mismatches can occur because the declarations are affected by previous preprocessing directives. For instance, a declaration occurs in a macro, and the macro is defined on one inclusion path but undefined in another. These declaration mismatches can be tricky to debug. Identify the divergence between the two inclusion paths and fix the conflicting macro definitions.

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

file1.c

int foo(void) { //Noncompliant
    return 1;
}

file2.c

double foo(void);

int bar(void) {
    return (int)foo();    
}

In this example, file1.c declares foo() as returning an integer. In file2.c, foo() is declared as returning a double. This difference raises a defect on the instance of foo in file1.

One possible correction is to change the function declarations so that they match. In this example, by changing the declaration of foo in file2.c to match file1.c, the defect is fixed.

file1.c

int foo(void) {
    return 1;
}

file2.c

int foo(void);

int bar(void) {
    return foo();
}

#include "square.h" 
#include "circle.h" 
struct aCircle circle; 
struct aSquare square;

int main(){ 
    square.side=1; 
    circle.radius=1;
    return 0;
}

#include "circle.h" 
#include "square.h" 
struct aCircle circle; 
struct aSquare square; //Noncompliant

int main(){ 
    square.side=1; 
    circle.radius=1;
    return 0;
}

#pragma pack(1)

extern struct aCircle{ 
    int radius; 
} circle; 

extern struct aSquare { 
    unsigned int side:1; 
} square;

In this example, a declaration mismatch defect is raised on square in square.h because Polyspace infers that square in square.h does not have the same alignment as square in test2.c. This error occurs because the #pragma pack(1) statement in circle.h declares specific alignment. In test2.c, circle.h is included before square.h. Therefore, the #pragma pack(1) statement from circle.h is not reset to the default alignment after the aCircle structure. Because of this omission, test2.c infers that the aSquare square structure also has an alignment of 1 byte.

One possible correction is to reset the structure alignment after the aCircle struct declaration. For the GNU^® or Microsoft^® Visual compilers, fix the defect by adding a #pragma pack() statement at the end of circle.h.

#include "square.h" 
#include "circle.h" 
struct aCircle circle; 
struct aSquare square;

int main(){ 
    square.side=1; 
    circle.radius=1;
    return 0;
}

#include "circle.h" 
#include "square.h" 
struct aCircle circle; 
struct aSquare square;

int main(){ 
    square.side=1; 
    circle.radius=1;
    return 0;
}

#pragma pack(1)

extern struct aCircle{ 
    int radius; 
} circle; 

#pragma pack()

extern struct aSquare { 
    unsigned int side:1; 
} square;

Other compilers require different #pragma pack syntax. For your syntax, see the documentation for your compiler.

One possible correction is to add the Ignore pragma pack directives option to your Bug Finder analysis. If you want the structure alignment to change for each structure, and you do not want to see this Declaration mismatch defect, use this correction.