unusedFunction inside #ifdef

[Dzid]

In the following example unusedFunction violation is raised even when Cppcheck is called with --force:

void func(void){
}
int main(void){
    #ifdef A
    func();
    #endif
}

This does not make sense to me because --force ineed explores the configuration (A) when the func is used.

[Andrew C Aitchison]

I think you need to have:

#ifdef A
void func(void){
}
#endif

int main(void){
#ifdef A
func();
#endif
}

That way there is no unused function even when A is ndef.

[Dzid]

I understand that this would solve it but it is not great. Imagine a list API functions being with some not being called depending on configuration. Polluting the API with #ifdef wouldn't be an my first choice.

I am looking for a confirmation whether this cppcheck behavior is intended or not and whether author's conviction is strong.

[Andrew C Aitchison]

I think idea of --force` is to warn if any ifdef configuration has a problem, not just if all of them do.

[Daniel Marjamäki]

Yes Cppcheck does not normally perform a "combined" analysis of configurations it checks each configuration individually.

However for the whole program analysis we probably don't distinguish configurations properly so I imagine that if the function is used in one configuration that cppcheck analyses there will not be a warning.

[Daniel Marjamäki]

I would expect that the warning is not shown if --force is used. And it works for me:

$ cppcheck --enable=unusedFunction -DX 1.c
Checking 1.c ...
Checking 1.c: X=1...
1.c:2:0: style: The function 'func' is never used. [unusedFunction]
void func(void){
^
nofile:0:0: information: Active checkers: 59/802 (use --checkers-report=<filename> to see details) [checkersReport]

$ cppcheck --enable=unusedFunction --force 1.c
Checking 1.c ...
Checking 1.c: A...
nofile:0:0: information: Active checkers: 59/802 (use --checkers-report=<filename> to see details) [checkersReport]

$ cat 1.c

void func(void){
}
int main(void){
    #ifdef A
    func();
    #endif
}

[Dzid]

Thank you for this. I got the same.

I need to reconsider my issues.

[Dzid]

It seems it behaves differently for some other checks, e.g unusedStructMember:

typedef struct {
    int x;
} X;

int main(void) {
    #ifdef A
    X x = {5};
    return x.x;
    #endif
}

/cppcheck --enable=all --addon=misra  1.c --force
Checking 1.c ...
1.c:3:9: style: struct member 'X::x' is never used. [unusedStructMember]
    int x;
        ^
Checking 1.c: A...
1.c:2:1: style: misra violation (use --rule-texts=<file> to get proper output) [misra-c2012-2.3]
typedef struct {
^
nofile:0:0: information: Active checkers: 107/802 (use --checkers-report=<filename> to see details) [checkersReport]

[Daniel Marjamäki]

I do consider that to be a false positive. However it's more difficult to fix. Most checkers checks 1 configuration at a time and if there is a problem in 1 configuration the warning will be shown.

For undefined behavior checks it's totally fine to warn if the problem only exists in 1 configuration. But yes in many "style" checks it would be better to check all configurations first.

Feel free to report some bugs in trac.