I will pay with PayPal (or bank transfer if you have an account in the
EU).
The fix must be included in the official Cppcheck version (so it must be
accepted by the Cppcheck team).
Members of the Cppcheck team are not excluded from this reward.
Best Regards
Volker Dirr
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you need to provide the qt library configuration. the qt library configuration is not loaded when you analyse the file directly. please try with my gui project.
as you can see you get an "unknown macro" error message and it points out a QT macro.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you for you answer. Our project has around 4000 cppcheck warnings with version 1.89.
But with cppcheck 1.90 most of them disappeared. Now there are only around 700 warnings left.
Of course some of them disappeared because you and the cppcheck team improved the cppcheck software. That is of course fine. But it looks like many of them also disappeared, even they should still be visible.
Can you please check the small example file that i added? You can reproduce the bug much better/easier there.
Maybe my first word is wrong. Not the whole file is skipped, but some checks are skipped.
Check the sample file. Why does the second warning disappear if the first bug is visible? It is totally independent and in an other file. That is wrong.
Last edit: Volker Dirr 2020-05-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you please check the small example file that i added? You can reproduce the bug much better/easier there.
Yes that is better.
I get these warnings:
cpp-bug-fet-source-liviu-minimum/generate.cpp:27:2: style: Statements following return, break, continue, goto or throw will never be executed. [unreachableCode]
cpp-bug-fet-source-liviu-minimum/generate.cpp:27:6: style: Unused variable: d [unusedVariable]
both when the line is commented out in the header or not
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah... Sorry. I answered from my E-Mail tool and it placed my answer at the wrong place. I just saw it now. I tried to delete them, but i can't.
I wanted to answer under your answer:
I can repruduce under linux and under windows.
I recorded a video, so you can see the bug: https://youtu.be/T9DjmBDowJ4
That is a bad bug :-(
It should work without that bug without doing some configuraions. Maybe there are even more configuarions needed and many other warnings are not visible? i loose a bit my trust into the results that i see.
So maybe a lot of guys can't see warnings, because they don't know how to setup the configuration correct?! It was working fine with 1.89 and below. But with 1.90 it started with strange behaviour.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let me know your IBAN or payPal account (you can write it by mail. see www.timetabling.de )
Or i can also donate just to your current kickstart project.
But i will keep (an other) 20€ reward for the guy that fix the bug. Not only try to avoid it by a trick.
Last edit: Volker Dirr 2020-05-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wonder a bit that you didn't add it into the bug tracker, because in my opinion this is a release blocker bug. Since it is in fact more critical than a crash, because users don't notice that it doesn't work correct and new users will thing all is fine. Only guys with a lot of warnings that already used cppcheck 1.89 or lower will notice that there is something totally wrong.
Since you didn't add it into bugtrack it mean you won't accept a fix? (In that case it will be impossible to get my second reward.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Of course a hard coded fix will be bad, since the same bug might/will happen with other macros.
The current warning is "bad", because:
- it is not clear that a lot of normal valid c code won't be checked anymore; but strangely a few checks will still be done
- it is just a single warning somewhere in a lot of warnings. As you can see we still have around 700 warnings with that bug and our project is just a small one, larger projects won't see it. It just looks like a minor warning in a lot of warnings.
So, in my opinion, there are at least 2 things useful:
- add a warning-comment like "BE CAREFUL. if you don't fix this bug most following warnings will be missing (or even wrong?!)".
- that warning should interrupt the scan. A user should confirm that he read this critical warning. AND/OR it should be added one more time as first and/or last bug, so it is easier to see.
An other point that is strange:
i didn't comment out the macro! The bug disappear if i comment out valid c code "bool tmp;". So it can be even fine with that macro?!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
maybe the bailout can be a bit less strict. If there is a unknown macro between a { and a private: maybe we can ignore that in the parser. I am not sure.
i didn't comment out the macro! The bug disappear if i comment out valid c code "bool tmp;". So it can be even fine with that macro?!
yes a bit surprising
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made it a bit less strict. You should get more warnings even without the qt.cfg .. however I strongly recommend that you check with qt.cfg anyway from now on. The analyze file/folder options are not really useful I think they should only be considered for quick and rough tests.
then.. how we can ensure that users will notice the unknownMacro errors better in the future is a good question.
some users fix the warnings that are shown .. or if they don't care about the warnings they suppress them. If that is done then this error message will not be hidden.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ahh.. You done it with this, didn't you: https://trac.cppcheck.net/changeset/9eda3993236863ffc7231c1b601ebf69f1f93d97
i modified the cppcheck source manualy, recompiled and checked.
it is working now fine with the small minimum example. That is much better
But if i scan our whole project, then there are still a few warings silent. i will try to trac it down and do a new minimum example about that bug.
yes, a better warning might be still useful. At least adding more information in the string that it is critical.
about the project. i never done it so far, since i always compiled myself cppcheck by using "qmake" and "make". But the executable is stored in the the gui folder. maybe you just add the upper folder in the pro file as destination, so it can find the cfg files.
i saw there are many other options that i can configure in a project file. is there somewhere a small manual about that?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, false alarm. I compared original cppcheck with qt cfg VS. new cppcheck without qt cfg.
i compared now new VS. original cppcheck; both with qt cfg.
in that case the results are the same.
i also check new VS. original cppcheck; both without qt cfg.
in that case there are nearly all warnings visible now, but/and the "There is an unknown macro here somewhere. " disappeared.
hmm...
so in my opinion this solution is very close to be perfect.
i am not sure. maybe a there should be a feature that automatically try to detect needed/useful cfg stuff?
I will donate the second reward as i said after the official 2.1 release. Mainly also because i bet you do a new kickstarter project again and i also bet it will be very hard to reach the goal. i have a bit the feeling always the same few guys donate. You need more advertisement for your kickstarter projects by better description of the project itself and by spreading it in other places, not only here in this new forum.
Last edit: Volker Dirr 2020-05-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Donated (Since you started a projekt once again.)
Someone should think about doing advertisment at other locations for this project, since i fear it will be hard to reach the goal again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Someone should think about doing advertisment at other locations for this project, since i fear it will be hard to reach the goal again.
Yes..
I want it to be directed somehow. It's a very low chance that people in general will be interested in it so it would be spam to advertise for everybody.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo Cppcheck fans,
sadly there is a very nasty bug. Cppcheck is not serviceable anymore for
larger projects.
I will pay a 20 Euro reward to the guy that is able to fix this bug:
https://sourceforge.net/p/cppcheck/discussion/general/thread/e13f7ada7e/
I will pay with PayPal (or bank transfer if you have an account in the
EU).
The fix must be included in the official Cppcheck version (so it must be
accepted by the Cppcheck team).
Members of the Cppcheck team are not excluded from this reward.
Best Regards
Volker Dirr
that is strange.
i get that 2 warnings only if i comment line 29 in rules.h
they disappear as soon as line 29 is not a comment.
i rechecked with official cppcheck 2.0.
i can reproduce the bug always.
do you have a suggestion? did you check cppcheck gui or command line
only i always use gui only and it is nor working with that :-(
Last edit: Volker Dirr 2020-05-16
I can repruduce under linux and under windows.
I recorded a video, so you can see the bug:
https://youtu.be/T9DjmBDowJ4
That is a bad bug :-(
you need to provide the qt library configuration. the qt library configuration is not loaded when you analyse the file directly. please try with my gui project.
as you can see you get an "unknown macro" error message and it points out a QT macro.
My guess is that Cppcheck is confused and that improved configuration would fix this.
When cppcheck is confused it should write an information message so the configuration can be fixed. That apparently does not happen here.
So the "bug fix" I guess would be to write a information message.
With this command I get many warnings:
~/cppcheck/cppcheck --enable=style --library=qt fet-5.42.0/src/engine/generate.cpp
Doesn't that work properly?
Hallo Daniel,
thank you for you answer. Our project has around 4000 cppcheck warnings with version 1.89.
But with cppcheck 1.90 most of them disappeared. Now there are only around 700 warnings left.
Of course some of them disappeared because you and the cppcheck team improved the cppcheck software. That is of course fine. But it looks like many of them also disappeared, even they should still be visible.
Can you please check the small example file that i added? You can reproduce the bug much better/easier there.
Maybe my first word is wrong. Not the whole file is skipped, but some checks are skipped.
Check the sample file. Why does the second warning disappear if the first bug is visible? It is totally independent and in an other file. That is wrong.
Last edit: Volker Dirr 2020-05-16
Yes that is better.
I get these warnings:
cpp-bug-fet-source-liviu-minimum/generate.cpp:27:2: style: Statements following return, break, continue, goto or throw will never be executed. [unreachableCode]
cpp-bug-fet-source-liviu-minimum/generate.cpp:27:6: style: Unused variable: d [unusedVariable]
both when the line is commented out in the header or not
I used the command line.
It also works in the GUI for me with this project file:
Last edit: Daniel Marjamäki 2020-05-16
Ah... Sorry. I answered from my E-Mail tool and it placed my answer at the wrong place. I just saw it now. I tried to delete them, but i can't.
I wanted to answer under your answer:
I can repruduce under linux and under windows.
I recorded a video, so you can see the bug:
https://youtu.be/T9DjmBDowJ4
That is a bad bug :-(
It should work without that bug without doing some configuraions. Maybe there are even more configuarions needed and many other warnings are not visible? i loose a bit my trust into the results that i see.
So maybe a lot of guys can't see warnings, because they don't know how to setup the configuration correct?! It was working fine with 1.89 and below. But with 1.90 it started with strange behaviour.
Let me know your IBAN or payPal account (you can write it by mail. see www.timetabling.de )
Or i can also donate just to your current kickstart project.
But i will keep (an other) 20€ reward for the guy that fix the bug. Not only try to avoid it by a trick.
Last edit: Volker Dirr 2020-05-16
feel free to donate to the Kickstarter project.
Done. Second reward still open.
I wonder a bit that you didn't add it into the bug tracker, because in my opinion this is a release blocker bug. Since it is in fact more critical than a crash, because users don't notice that it doesn't work correct and new users will thing all is fine. Only guys with a lot of warnings that already used cppcheck 1.89 or lower will notice that there is something totally wrong.
Since you didn't add it into bugtrack it mean you won't accept a fix? (In that case it will be impossible to get my second reward.)
I will in theory accept a fix if it does not cause false positives and crashes.
we try to handle unknown macros. if they folllow normal c/c++ syntax then the parser can make reasonable guesses.
we bailout and write unknownMacro when the parser cant make a sage guess and it would lead to crashes hangs false positives to continue.
some hardcoded handling for qt will not be acceptable.
I agree it would be a huge problem if we were silent and did not tell the user we bailout.
maybe the error message can be more clear?
Of course a hard coded fix will be bad, since the same bug might/will happen with other macros.
The current warning is "bad", because:
- it is not clear that a lot of normal valid c code won't be checked anymore; but strangely a few checks will still be done
- it is just a single warning somewhere in a lot of warnings. As you can see we still have around 700 warnings with that bug and our project is just a small one, larger projects won't see it. It just looks like a minor warning in a lot of warnings.
So, in my opinion, there are at least 2 things useful:
- add a warning-comment like "BE CAREFUL. if you don't fix this bug most following warnings will be missing (or even wrong?!)".
- that warning should interrupt the scan. A user should confirm that he read this critical warning. AND/OR it should be added one more time as first and/or last bug, so it is easier to see.
An other point that is strange:
i didn't comment out the macro! The bug disappear if i comment out valid c code "bool tmp;". So it can be even fine with that macro?!
maybe the bailout can be a bit less strict. If there is a unknown macro between a
{and aprivate:maybe we can ignore that in the parser. I am not sure.yes a bit surprising
I made it a bit less strict. You should get more warnings even without the qt.cfg .. however I strongly recommend that you check with qt.cfg anyway from now on. The analyze file/folder options are not really useful I think they should only be considered for quick and rough tests.
then.. how we can ensure that users will notice the unknownMacro errors better in the future is a good question.
some users fix the warnings that are shown .. or if they don't care about the warnings they suppress them. If that is done then this error message will not be hidden.
ahh.. You done it with this, didn't you: https://trac.cppcheck.net/changeset/9eda3993236863ffc7231c1b601ebf69f1f93d97
i modified the cppcheck source manualy, recompiled and checked.
it is working now fine with the small minimum example. That is much better
But if i scan our whole project, then there are still a few warings silent. i will try to trac it down and do a new minimum example about that bug.
yes, a better warning might be still useful. At least adding more information in the string that it is critical.
about the project. i never done it so far, since i always compiled myself cppcheck by using "qmake" and "make". But the executable is stored in the the gui folder. maybe you just add the upper folder in the pro file as destination, so it can find the cfg files.
i saw there are many other options that i can configure in a project file. is there somewhere a small manual about that?
Sorry, false alarm. I compared original cppcheck with qt cfg VS. new cppcheck without qt cfg.
i compared now new VS. original cppcheck; both with qt cfg.
in that case the results are the same.
i also check new VS. original cppcheck; both without qt cfg.
in that case there are nearly all warnings visible now, but/and the "There is an unknown macro here somewhere. " disappeared.
hmm...
so in my opinion this solution is very close to be perfect.
i am not sure. maybe a there should be a feature that automatically try to detect needed/useful cfg stuff?
I will donate the second reward as i said after the official 2.1 release. Mainly also because i bet you do a new kickstarter project again and i also bet it will be very hard to reach the goal. i have a bit the feeling always the same few guys donate. You need more advertisement for your kickstarter projects by better description of the project itself and by spreading it in other places, not only here in this new forum.
Last edit: Volker Dirr 2020-05-17
You released 2.1 several weeks before schedule?! (in normal case you are a bit behind schedule :-)
Ok. I rechecked it and it looks fine now. So i will wait for your next kickstarter project to do the next reward.
Donated (Since you started a projekt once again.)
Someone should think about doing advertisment at other locations for this project, since i fear it will be hard to reach the goal again.
Yes..
I want it to be directed somehow. It's a very low chance that people in general will be interested in it so it would be spam to advertise for everybody.