Declaration mismatch

Mismatch between function or variable declarations

Description

This checker is deactivated in a default Polyspace^® as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).

This defect occurs when a function or variable declaration does not match other instances of the function or variable.

Risk

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.

Fix

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:

Address Results in Polyspace User Interface Through Bug Fixes or Justifications if you review results in the Polyspace user interface.
Address Results in Polyspace Access Through Bug Fixes or Justifications (Polyspace Access) if you review results in a web browser.
Annotate Code and Hide Known or Acceptable Results if you review results in an IDE.

Examples

expand all

Inconsistent Declarations in Two Files

file1.c

int foo(void) {
    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 might cause a compile failure. Polyspace raises a defect on the second instance of foo in file2.

Correction — Align the Function Return Values

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();
}

Inconsistent Structure Alignment

test1.c

#include<stdio.h>
#include "square.h" 
#include "circle.h" 
struct aCircle circle; 
struct aSquare square;

void func2();

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

test2.c

#include<stdio.h>
#include "circle.h" 
#include "square.h" 
struct aCircle circle; 
struct aSquare square;

void func2(){ 
    printf("%d\n", square.side); 
    printf("%d\n", circle.radius);
}

circle.h

#pragma pack(1)

extern struct aCircle{ 
    int radius; 
} circle;

square.h

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

In this example, a declaration mismatch defect is raised on square in test2.c 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. This defect might cause a compilation failure.

Correction — Close Packing Statements

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.

test1.c

#include<stdio.h>
#include "square.h" 
#include "circle.h" 
struct aCircle circle; 
struct aSquare square;

void func2();

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

    func2();
    return 0;
}

test2.c

#include<stdio.h>
#include "circle.h" 
#include "square.h" 
struct aCircle circle; 
struct aSquare square;

void func2(){ 
    printf("%d\n", square.side); 
    printf("%d\n", circle.radius);
}

circle.h

#pragma pack(1)

extern struct aCircle{ 
    int radius; 
} circle; 

#pragma pack()

square.h

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

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

Correction — Use the Ignore pragma pack directives Option

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.

On the Configuration pane, select the Advanced Settings pane.
In the Other box, enter -ignore-pragma-pack.
Rerun your analysis.
The Declaration mismatch defect is resolved.

Result Information

Group: Programming

Language: C | C++

Default: On

Command-Line Syntax: DECL_MISMATCH

Impact: High

Version History

Introduced in R2013b

expand all

R2024b: Lambda objects no longer flagged

Polyspace no longer reports a violation of this rule on lambda objects.

R2024a: `rand()` function no longer flagged when not using the C standard library

Starting in R2024a, Polyspace no longer reports a violation of this rule if you define an external rand() function and you do not use rand() from the C standard library. A violation can still occur if the user-defined rand() definition and declaration do not match.

extern char rand(char c);     //Compliant

int main(void) {
  char i = rand('c');
  return 0;
}

R2023b: `volatile` and `const` parameter qualifiers no longer flagged when considered equivalent

Starting in R2023b, Polyspace no longer reports violations of this rule when a function definition contains a const or volatile qualifier, but the function declaration does not use the same const or volatile qualifier. This exception only applies when the qualifier is at the outermost level of the parameter type specification. Such instances are compliant because the compiler considers the parameter definitions equivalent, despite the added presence of const or volatile qualifiers.

For example:

int foo(int i);

int foo(const int i) {	//Compliant
	//...
}

void bar() {
  int val = 42;
  foo(0);
  foo(val);
}

Declaration mismatch

Description

Risk

Fix

Examples

Inconsistent Declarations in Two Files

Inconsistent Structure Alignment

Result Information

Version History

R2024b: Lambda objects no longer flagged

R2024a: `rand()` function no longer flagged when not using the C standard library

R2023b: `volatile` and `const` parameter qualifiers no longer flagged when considered equivalent

See Also

Topics

Declaration mismatch

Description

Risk

Fix

Examples

Inconsistent Declarations in Two Files

Inconsistent Structure Alignment

Result Information

Version History

R2024b: Lambda objects no longer flagged

R2024a: rand() function no longer flagged when not using the C standard library

R2023b: volatile and const parameter qualifiers no longer flagged when considered equivalent

See Also

Topics

R2024a: `rand()` function no longer flagged when not using the C standard library

R2023b: `volatile` and `const` parameter qualifiers no longer flagged when considered equivalent