Community
Participate
Working Groups
In following (not very nice) code codan thinks that brace in #if 0 branch matches the last one and thus the function opening brace has no closing counterpart. Surprisingly no code analysis error is reported. void test() { int x = 1; #if 0 if (x == 1) { #else if (x == 0) { #endif x = 2; } }
Codan does not parse ifdefs, it would be preprocessor. I am not sure what is the problem, if you don't see any errors how do you know what "it thinks"?
I have tried the same with 8.4 CDT version and the problem is still there. Steps to reproduce: 1. use test code void test() { int x = 1; #if 0 if (x == 1) { #else if (x == 0) { #endif x = 2; } } 2. move cursor to the function opening bracket and push shortcut to jump to the matching bracket - nothing happens 3. move cursor to the function closing bracket, brace in #if 0 branch is highlighted, jump to the matching brace - voila we are in #if 0 preprocessor branch
I forgot to mention that all code following such function has broken bracket matching. That was the reason for me hitting this bug...
Bracket matcher does not even use preprocessor I think, has nothing to do with codan for sure. I will switch it to editor, I am not sure where it goes.
Bug 222032 is similar (it concerns the highlighting of the matching brace, not navigation to it, but presumably those use the same analysis under the hood). Personally, code where a preprocessor branch covers one of a pair of matching braces but not another, seems very messy to me. I rarely if ever encounter code like this in the codebases I work on.
I agree that similar code style is ugly and messy, but unfortunately I meet this pretty often in legacy code that I work with... I'm surprised that this behavior is here 2008 (according to linked bug) and there is no more people discussing it :)
