Activity for dcb
-
dcb posted a comment on discussion General Discussion
Given this C++ code: include <string></string> include <vector></vector> using namespace std; void f( string a) { } void g( vector < string > b) { } then cppcheck says the same thing for both functions: apr18b.cc:9:16: performance: Function parameter 'a' should be passed by const reference. [passedByValue] void f( string a) ^ apr18b.cc:13:27: performance: Function parameter 'b' should be passed by const reference. [passedByValue] void g( vector < string > b) Since copying a vector of strings will...
-
Option 2, please. I am happy to report bugs, but I don't do pull requests.
-
I found a message that looks slightly wrong. trunk $ grep "There was critical" lib/*.cpp lib/checkersreport.cpp: fout << "There was critical errors (" << criticalErrors << ")" << std::endl; trunk $ In proper English, "There was" with plurals should be "There were".
-
Hello there, The bug remains unfixed after three years, so I won't bother resubmitting it. Regards David Binderman From: bugs@tn5250.p.re.sourceforge.net bugs@tn5250.p.re.sourceforge.net on behalf of Kevin Adler kadler@users.sourceforge.net Sent: 17 October 2023 13:14 To: [tn5250:bugs] 46@bugs.tn5250.p.re.sourceforge.net Subject: [tn5250:bugs] #46 session.c:2949: bad compare ? status: open --> wont-fix Comment: Hi, if you are still experiencing this problem, please open an issue at https://github.com/tn5250/tn5250/issues...
-
The bug remains unfixed after three years, so it seems pretty pointless to resubmit it. A fix looks unlikely.
-
I haven't seen your CI before, so it can be no surprise that I see no evidence of a build by gcc or clang from today in it. I tried a git pull, just in case something had changed during the day. It didn't help. I have a self generated fix, so cppcheck builds for me here. I think that's about as far as I want to go with this. Thanks for your help.
-
$ git diff lib/settings.cpp diff --git a/lib/settings.cpp b/lib/settings.cpp index 896341a..7b62612 100644 --- a/lib/settings.cpp +++ b/lib/settings.cpp @@ -24,6 +24,7 @@ #include <fstream></fstream> #include "json.h" +#include "timer.h" std::atomic<bool> Settings::mTerminated;</bool> So I think lib/settings.cpp is up to date. In your CI, which C++ compiler do you use ? Perhaps Microsoft ?
-
Yesterday's cppcheck built fine. Not today. A compile error about SHOWTIME_NONE lib/settings.cpp: In constructor ‘Settings::Settings()’: lib/settings.cpp:69:30: error: ‘SHOWTIME_NONE’ is not a member of ‘SHOWTIME_MODES’ 69 | showtime(SHOWTIME_MODES::SHOWTIME_NONE), | ^~~~~~~~~~~~~ clang and g++ refuse to compile it, so I have no idea which compiler accepted the code. I ran the preprocessor only and grepped for SHOWTIME: $ grep SHOWTIME /tmp/q.ii enum class SHOWTIME_MODES; SHOWTIME_MODES showtime{};...
-
The following warnings are produced from a recent trunk version of gcc: lib/keywords.cpp:165:1: warning: control reaches end of non-void function [-Wreturn-type] lib/keywords.cpp:184:1: warning: control reaches end of non-void function [-Wreturn-type] lib/keywords.cpp:200:1: warning: control reaches end of non-void function [-Wreturn-type] lib/keywords.cpp:220:1: warning: control reaches end of non-void function [-Wreturn-type] externals/picojson/picojson.h:249:10: warning: ‘<unnamed>.picojson::value::u_’...
-
lib/checkcondition.cpp:490:9: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] lib/checkcondition.cpp:552:9: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] lib/checkcondition.cpp:814:9: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] lib/checkcondition.cpp:829:9: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] lib/checkcondition.cpp:844:9: warning: use of bitwise '&'...
-
apply the changes in PR 5015? Yes and the changes make it work for both gcc and clang. Thanks very much ! Some warnings were produced, I will make those the subject of another thread.
-
Two workarounds: The static assert went into gcc trunk on 2022-12-14, so use a compiler from before then. 20221204 seems to work. More brutally, remove the static assert from the alloc_traits.h header file. This will affect other builds.
-
Do you see some bleeding edge C++ code? Yes, use of lambdas. They have only been around since C++11 and have been enhanced ever since (C++14, C++17). That's probably ok if cppcheck only had to work with one compiler. I'd be interested to find out which C++ compiler accepts the current cppcheck code. MS maybe ?
-
Thanks for the information. Given that cppcheck has to compile with a variety of C++ compilers, I'd be tempted to rework the cppcheck code into something most C++ compilers can easily accept. Writing bleeding edge C++ code that some compilers have trouble implementing is IMHO asking for trouble.
-
Fedora 38 has been released with new gcc-13. Some newish C++ syntax for lambdas in the source code of cppcheck doesn't compile. /usr/include/c++/13/bits/alloc_traits.h: In instantiation of ‘struct std::__allocator_traits_base::__rebind<taggedallocator\<referencetoken, 3="">, ReferenceToken, void>’: /usr/include/c++/13/bits/alloc_traits.h:94:11: required by substitution of ‘template<class _alloc,="" class="" _up=""> using std::__alloc_rebind = typename std::__allocator_traits_base::__rebind<_Alloc,...
-
shk.c:4733: bad precedence ?
-
path_utils.c:89: possible bad precedence ?
-
strings.c:273: possible missing comma ?
-
icns2png.c:70: possible missing "," ?
-
ixpm.c: 2 * off by one error ?
-
I just tried to compile today's trunk cppcheck with new C/C++ compiler clang-14. It said: $ fgrep warning: mk.clang.out lib/checkcondition.cpp:477:9: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] lib/checkcondition.cpp:538:9: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] lib/checkcondition.cpp:804:9: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] lib/checkcondition.cpp:819:9: warning: use of bitwise...
-
GContainer.h:860: bad call to memset ?
-
GBitmap.cpp:102:55: warning: member ' DJVU::GBitmap::bytes_data' is used uninitialized [-Wuninitialized]
-
ArchiveCommandLine.cpp:396:10: warning: duplicated 'if' condition
-
genlex.c:2435:18: warning: dup licated 'if' condition
-
save.c:525:37: warning: duplicated ‘if’ condition
-
src/tuxpaint.c:3311: duplicate condition ?
-
sbr_dec.c:484: wrong buffer size ?
-
It looks to me like your most recent code is irrelevant to the point I was trying to make. My apologies for the confusion. AFAIK, the casts in the original code don't affect anything. The code is essentially bool DataBase::IsValid() { if (something) return IsValid(); else return IsValid(); } which is why the clang compiler is getting upset. After this many years, however broken the code may or not be, you clearly aren't that bothered about fixing it, so it looks to me like continuing to find bugs...
-
Filetypes.cpp:363: infinite-recursion
-
I had a quick look at the new code and the thought struck me that if the event list is sorted on time and there are more than a few events in the list, then binary search would be faster than serial search. I am not sure where the breakeven point is, but it might be as few as 10 events. Just an idea.
-
src/gui/editors/eventlist/EventView.cpp:676: suspicious if ?
-
session.c:2949: bad compare ?
-
asn_bits.c:348: bad compare ?
-
It works fine with --inconclusive flag. $ /home/dcb/cppcheck/trunk/cppcheck --enable=all --inconclusive may8e.cc may8e.cc:14:6: style:inconclusive: Technically the member function 'S::getFred' can be const. [functionConst] int getFred() { return fred; }; ^ may8e.cc:14:0: style: The function 'getFred' is never used. [unusedFunction] ^ $ Fast work. Thanks very much for your help.
-
For this C++ source code: class S { private: int fred; public: S( int n) : fred( n) { }; ~S() {}; int getFred() { return fred; }; }; where the member function body is only a return statement and so the member function could be made const, cppcheck doesn't detect this situation. $ /home/dcb/cppcheck/trunk/cppcheck --enable=all may8e.cc may8e.cc:14:0: style: The function 'getFred' is never used. [unusedFunction] $ I am not sure if this is a feature request or a bug report.
-
strings.c: 2 * bad test
-
gnuplot-5.2.7/src/readline.c:455: possible missing break ?
-
run.c:1626: suspicious assignment
-
gtkdatabox_ruler.c: 3 * possible bad use of '&' ?
-
Like which tool is generating this errors? cppcheck. From sourceforge. Recommended for all C/C++ code.
-
directorymonitor.cpp:363: bad erase ?
-
event_zone.cc:71]: (warning) Member variable 'event_zone::active' is not assigned a value
-
netsys_c_mem.c:1252: pointless call to strcmp ?
-
gtkiconlist.c: src and dest on sprintf can't match
-
arcmisc.c:131]: (error) Resource leak: old
-
tilp_config.c:235]: (error) Resource leak: txt
-
slpd_main.c:366]: (error) Resource leak: fd
-
sahpi_gcrypt_utils.c:232]: (error) Resource leak: fconf
-
AuErrDes.c:177]: (error) Resource leak: fp
-
5 * missing return statements
-
libmpeg3/mpeg3title.c:194: bad call to fprintf ?
-
plugins/hyperlapse/hyperlapse.C:59: bad compares ?
-
Three year old compiler is very old. Current released version of gcc is 7.2 - I am using 8.0 (development snapshot). Suggest upgrade, if you can.
-
history.c: 3 * bad memset size ?
-
eval.c:466: suspicious assignment ?
-
popupmenu.cc:979: bad type ?
-
RunParameters.cpp:270: bad type ?
-
src/svf/svf.c:1314: bad if ?
-
ADM_videoFilters/BlendRemover/ADM_vidBlendRemoval.cpp:151: bad compare ?
-
eval.c:438]: (warning) Redundant assignment
-
I'd done worse than that: I've emailed Keiichi Tokuda ( the maintainer) with the bug report. Let's see if they can come up with a reasonable fix.
-
3rdparty/hts_engine_API/lib/HTS_model.c:1168: bad compare ?
-
rcfile.c:152: bad width ?
-
zip.cpp: 9 * bad catch type ?
-
2 * bad catch type ?
-
Aiksaurus.cpp: 4 * bad catch ?
-
backend_shinkos1245.c:500:27: warning: '<<' in boolean context, did you mean '<' ? [-Wint-in-bool-context]
-
test6.c: 6 * possible faulty expression ?
-
CellBuffer.cxx: 2 * badly placed sanity check ?
-
Ft/Xml/src/domlette/content_model.c:356: read bad data ?
-
icon-theme.c:174: broken code ?
-
DivFix++.cpp:37: ordering mixup ?
-
utimecmp.c: 2* bad operator on bool value ?
-
fedora/pass20/20170109/splix.spec.out:src/cache.cpp:245:25: warning: '~' on an expression...
-
src/heapy/hv_cli_findex.c:102: bad if statement ?
-
iptc-data.c:607: poor error checking ?
-
qjackctlSetupForm.cpp:835: possible missing break ?
-
ngrep.c: multiple missing breaks ?
-
c_src/esdl_video.c:169: possible missing break ?
-
genpictex.c:399: bad if test ?
-
acpi.h:22: bad header guard ?
-
tinyxml.h:353: sanity check wrong way around ?
-
gpdis.c:632: bad if test ?
-
memory leaks ?
-
four memory leaks ?
-
src/base64.c:212]: (error) Memory leak: outbuf
-
rtfconvert.c: 2 * possible botch in sizeof ?
-
sliding_window.c: 2 * undefined code ?
-
test-pdc.h:92: bad sizeof ?
-
qtractorDssiPlugin.h:22: bad macro ?
-
nativebarclient.h:19: bad macro ?
-
httpencode.cpp:62: cart before the horse ?
-
db_x509.cpp:521]: (error) Mismatching allocation and deallocation: cert
-
| and || mixup ?
-
bltUnixDnd.c:1251]: (style) Same expression on both sides of '&&'
-
system.c:3686]: (error) Resource leak: fp
-
include/cddb/cddb_log.h:22: bad define ?
-
source/expression_filter.cpp: 2* bad expression ?
1 >
