cppcheck Activity
Static source code analysis tool for C and C++ code
Brought to you by:
danielmarjamaki
Activity for cppcheck
-
CHR posted a comment on discussion General Discussion
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14624
-
Nikita Leontiev posted a comment on discussion General Discussion
cppcheck 2.20.0 generates wrongPrintfScanfArgNum for the following code: #include <stdio.h> int main() { const char* str = "test."; const size_t size = 5; char buffer[size]; sscanf_s(str, "%4[^.]", buffer, size); return 0; } test\main.cpp:8:2: error: sscanf_s format string requires 3 parameters but only 2 are given. [wrongPrintfScanfArgNum] sscanf_s(str, "%4[^.]", buffer, size); ^
-
Will be fixed by https://github.com/danmar/cppcheck/pull/8301 There is an issue with using covered by https://trac.cppcheck.net/ticket/14578
-
Feature request: ability to enable SafeChecks via command line arg.
-
cppcheck 2.20.0 doesn't generate useStlAlgorithm for the following code: #include <string> #include <vector> #include <windows.h> using std::wstring; class Object { private: wstring m_str; public: Object() : m_str(L"str") {} const wstring& get_str() const { return m_str; } }; Object* func(const std::vector<Object*>& objects) { for (std::vector<Object*>::const_iterator it = objects.begin(); it != objects.end(); ++it) { if (!lstrcmpi((*it)->get_str().c_str(), L"str")) return *it; } return NULL; } useStlAlgorithm...
-
cppcheck 2.20.0 doesn't generate useStlAlgorithm for the following code: #include <string> #include <vector> #include <windows.h> using std::wstring; class Object { private: wstring m_str; public: Object() : m_str(L"str") {} const wstring& get_str() const { return m_str; } }; Object* func(const std::vector<Object*>& objects) { for (std::vector<Object*>::const_iterator it = objects.begin(); it != objects.end(); ++it) { if (!lstrcmpi((*it)->get_str().c_str(), L"str")) return *it; } return NULL; } useStlAlgorithm...
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14575
-
If you want this merged, please open a PR at https://github.com/danmar/cppcheck/pulls
-
ams21 posted a comment on discussion Development
I've noticed since version 2.19.0 building with musl libc (alpine for example). I get the following error: /dev/cppcheck/cli/stacktrace.cpp:29:10: fatal error: execinfo.h: No such file or directory 29 | #include <execinfo.h> | ^~~~~~~~~~~~ But using the following patch it works: diff --git a/lib/config.h b/lib/config.h index a63cf773d..d29e630f6 100644 --- a/lib/config.h +++ b/lib/config.h @@ -206,7 +206,7 @@ #define USE_WINDOWS_SEH #endif -#if !defined(NO_UNIX_BACKTRACE_SUPPORT) && defined(__GNUC__)...
-
cppcheck 2.20.0 doesn't generate constVariablePointer for the following code: #include <string> using std::wstring; class Object { private: wstring m_str; public: Object() : m_str(L"str") {} const wstring& get_str() const { return m_str; } }; Object* get_object() { static Object obj; return &obj; } void func(const wchar_t*) {} int main() { Object* obj = get_object(); func(obj->get_str().c_str()); return 0; } obj can be pointer to const. constVariablePointer is generated with --std=c++03 arg: test\main.cpp:24:10:...
-
Zufu Liu posted a comment on discussion Development
cppcheckgui.exe crashed (without messages, where can I find crash logs?) when open and check https://github.com/zufuliu/notepad4/blob/main/Notepad4.cppcheck but command line cppcheck.exe --project="D:\notepad4\notepad4\build\VisualStudio\Notepad4.sln" --project-configuration="Release|x64" finished without crash and shows some [ctuOneDefinitionRuleViolation] warnings at end. It seems command line cppcheck.exe not support Cppcheck own project file? cppcheck.exe --project="D:\notepad4\notepad4\Notepad4.cppcheck"...
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14571
-
Daniel Marjamäki modified a comment on discussion Development
It is much cleaner to construct the variable with the correct type instead of using a static_cast, +1 I also see such somewhat related code now and then: auto s = std::string{"hello"};
-
so as I read it we think that example 2 and example 3 are OK. I believe that example 1 is discussible. There may be situations where auto is preferable and then there are situations where it would be better to remove the cast and not use auto. Imho, the downsides of the auto+cast is that it's extra code and it can hide compiler warnings that may point out real bugs.
-
cppcheck 2.20.0 doesn't generate constVariablePointer for the following code: #include <string> class Object { private: std::string m_str; public: Object() : m_str("str") {} const std::string& get_str() const { return m_str; } }; char buffer[256]; struct Item { char* m_buffer; Item() : m_buffer(buffer) {} }; struct Wrapper { Item m_item; }; Object* get_object() { static Object object; return &object; }; int main() { Wrapper wrap; Item& item = wrap.m_item; Object* obj = get_object(); strcpy(item.m_buffer,...
-
It is much cleaner to construct the variable with the correct type instead of using a static_cast, +1 casts can hide compiler warnings about real bugs. I also see such somewhat related code now and then: auto s = std::string{"hello"};
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14567
-
itzexpoexpo posted a comment on discussion General Discussion
Cppcheck 2.20.0 flags this code: template <typename test_t> concept MRE = requires() { std::is_aggregate_v<test_t>; } || requires() { std::is_standard_layout_v<test_t>; }; with the following error: test.cpp:5:59: error: Syntax Error: AST broken, binary operator '||' doesn't have two operands. [internalAstError] concept MRE = requires() { std::is_aggregate_v<test_t>; } || requires() { std::is_standard_layout_v<test_t>; }; this error occurs only if a parameter list is present (empty or otherwise),...
-
Thanks for reporting, see https://trac.cppcheck.net/ticket/14564
-
cppcheck 2.20.0 generates AssignmentIntegerToAddress for the following code: #include <windows.h> int main() { int first_id = 1; int res = 5; const char* ptr = MAKEINTRESOURCE(res - first_id); (void)ptr; return 0; } cppcheck.exe --enable=all --library=windows . test\main.cpp:7:18: portability: Assigning an integer to a pointer is not portable. [AssignmentIntegerToAddress] const char* ptr = MAKEINTRESOURCE(res - first_id); ^ MAKEINTRESOURCE: #define MAKEINTRESOURCEA(i) ((LPSTR)((ULONG_PTR)((WORD)(i))))...
-
cppcheck 2.20.0 generates AssignmentIntegerToAddress for the following code: #include <windows.h> int main() { int first_id = 1; int res = 5; const char* ptr = MAKEINTRESOURCE(res - first_id); (void)ptr; } cppcheck.exe --enable=all --library=windows . test\main.cpp:7:18: portability: Assigning an integer to a pointer is not portable. [AssignmentIntegerToAddress] const char* ptr = MAKEINTRESOURCE(res - first_id); ^ MAKEINTRESOURCE: #define MAKEINTRESOURCEA(i) ((LPSTR)((ULONG_PTR)((WORD)(i)))) cppcheck...
-
So you would like to see the warning without --library=windows, right? Yes
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14560
-
So you would like to see the warning without --library=windows, right? I have created this ticket: https://trac.cppcheck.net/ticket/14559
-
So you would like to see the warning with --library=windows, right?
-
Isn't this a true positive? The code below compiles just fine. int GetSysColor(int); class CColor { private: int m_color; public: CColor() : m_color(1) {} int get_color() const { return m_color; } }; class CWrapper { private: CColor *m_color; public: explicit CWrapper(CColor* color) : m_color(color) {} CColor* get_color() const { return m_color; } }; int test(const CWrapper & wrap) { const CColor *color = wrap.get_color(); return GetSysColor(color?color -> get_color():1); }
-
Same false positive with SetupDiGetDeviceInstanceId: #include <windows.h> #include <SetupAPI.h> void GetDeviceInstanceId(HDEVINFO info, SP_DEVINFO_DATA *data) { const DWORD buffer_size = 256; char buffer[buffer_size]; SetupDiGetDeviceInstanceId(info, data, buffer, buffer_size, NULL); } test\main.cpp:1:2: information: Include file: <windows.h> not found. Please note: Standard library headers do not need to be provided to get proper results. [missingIncludeSystem] #include <windows.h> ^ test\main.cpp:2:2:...
-
cppcheck 2.20.0 generates constParameterPointer for the following code: #include <windows.h> HWND CreateMessageWnd(void* param) { return CreateWindow(L"MessageWnd", NULL, 0, 0, 0, 0, 0, HWND_MESSAGE, NULL, NULL, param); } cppcheck.exe --enable=all --library=windows . test\main.cpp:1:2: information: Include file: <windows.h> not found. Please note: Standard library headers do not need to be provided to get proper results. [missingIncludeSystem] #include <windows.h> ^ test\main.cpp:3:29: style: Parameter...
-
Same false positive with SetupDiGetDeviceInstanceId: #include <windows.h> #include <SetupAPI.h> void GetDeviceInstanceId(HDEVINFO info, SP_DEVINFO_DATA *data) { const DWORD buffer_size = 256; char buffer[buffer_size]; SetupDiGetDeviceInstanceId(info, data, buffer, buffer_size, NULL); } test\main.cpp:1:2: information: Include file: <windows.h> not found. Please note: Standard library headers do not need to be provided to get proper results. [missingIncludeSystem] #include <windows.h> ^ test\main.cpp:2:2:...
-
cppcheck 2.20.0 generates constParameterPointer for the following code: #include <windows.h> HWND CreateMessageWnd(void* param) { return CreateWindow(L"MessageWnd", NULL, 0, 0, 0, 0, 0, HWND_MESSAGE, NULL, NULL, param); } cppcheck.exe --enable=all --library=windows . test\main.cpp:1:2: information: Include file: <windows.h> not found. Please note: Standard library headers do not need to be provided to get proper results. [missingIncludeSystem] #include <windows.h> ^ test\main.cpp:3:29: style: Parameter...
-
cppcheck 2.20.0 generates constVariablePointer for the following code: #include <windows.h> class CColor { private: int m_color; public: CColor() : m_color(1) {} int get_color() const { return m_color; } }; class CWrapper { private: CColor *m_color; public: explicit CWrapper(CColor* color) : m_color(color) {} CColor* get_color() const { return m_color; } }; int test(const CWrapper & wrap) { CColor *color = wrap.get_color(); return GetSysColor(color?color -> get_color():1); } cppcheck.exe --enable=all...
-
Christoph posted a comment on discussion General Discussion
I know. I ended up using chrpath to work around this issue. After creating the 2.20 package, I tried to remove the work around. To my surprise, it works now. So probably a no-issue, but I still don't know what happened with 2.19.
-
Cppcheck-2.20.0
-
cppcheck released /cppcheck/2.20/cppcheck-2.20.0.zip
-
-
-
-
Paul Fultz posted a comment on discussion Development
The problem with example 1 is the static_cast. I do find this common pattern with AI generated code. It is much cleaner to construct the variable with the correct type instead of using a static_cast, like char t = type or char t{type}. I actually have an addon that checks for these redundant casts: @cppcheck.checker def RedundantCast(cfg, data): for token in cfg.tokenlist: if not token.variable: continue m = match(token, "%var%@decl ; %var%@assign = static_cast <*>@cast (*) ;") if not m: continue...
-
Oliver Stöneberg posted a comment on discussion Development
I think all three are valid. Example 1 is not about saving code but redundancies. The type is clearly specified so there is no need to specify it again. So that should be done. Example 2 it would help understanding the code but if you are using a proper IDE the tooltip should take care of that. Example 3 it saves a lot of space and I think this is about the as_const() as well. I think that is a good use of auto and again the IDE tooltip would be good here. Buit in case of 2 or 3 I could go either...
-
I feel that auto is overused in cppcheck. And would like to have a little discussion about it. I don't want that we just mechanically replace types with auto whenever possible. Can we agree on when it is OK to use it. Example 1: Cast result assigned to variable: const auto t = static_cast<char>(type); I am not convinced that auto is a good idea if the typename is short and simple. It does not save any bytes to write auto here. If we just save 2-3 bytes by writing auto I still suggest we should write...
-
I feel that auto is overused in cppcheck. And would like to have a little discussion about it. I don't want that we just mechanically replace types with auto whenever possible. Can we agree on when it is OK to use it. Example 1: Cast result assigned to variable: const auto t = static_cast<char>(type); I am not convinced that auto is a good idea if the typename is short and simple. It does not save any bytes to write auto here. If we just save 2-3 bytes by writing auto I still suggest we should write...
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14548
-
NRK posted a comment on discussion General Discussion
Minimal reproducer: [/tmp]~> cat test.c typedef struct { char *s; int len; } Str; void f(int n) { Str tmp = {0}; Str s = n == 0 ? (Str){0} : tmp; } [/tmp]~> cppcheck test.c Checking test.c ... test.c:6:17: error: Syntax Error: AST broken, ternary operator lacks ':'. [internalAstError] Str s = n == 0 ? (Str){0} : tmp; ^ Wrapping the compound literal in a paren seems to solve it: [/tmp]~> cat test2.c typedef struct { char *s; int len; } Str; void f(int n) { Str tmp = {0}; Str s = n == 0 ? ((Str){0})...
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14540
-
Bassam Abdul-Baki posted a comment on discussion General Discussion
I'm getting an error for the following line of code. The if statement forces it to be a positive shift value. Sadly, it's not my code. if (bit_count < 0) { /*+ shift out the extra bits */ * ((UNSIGNED_32 *) extract_value_ptr) >>= (0 - bit_count); }
-
Yun modified a comment on discussion Development
Thanks for the suggestions. Just to clarify the context: I actually found this crash while fuzzing the harness. Since fuzzing drivers can sometimes produce false positives, I made sure to verify that this specific case is fully reproducible from the main entry point. I did use Claude to help structure and draft the PoC report for better readability ( comments are also polished by AI to improve my English writing ;). The main reason I haven't opened a PR yet is that I wanted to get the crash confirmed...
-
Thanks for the suggestions. Just to clarify the context: I actually found this crash while fuzzing the harness. Since fuzzing drivers can sometimes produce false positives, I made sure to verify that this specific case is fully reproducible from the main entry point. I did use Claude to help structure and draft the PoC report for better readability ( comments are also polished by AI to improve my English writing ;). The main reason I haven't opened a PR yet is that I wanted to get the crash confirmed...
-
Also note that this is detected by Clang: <source>:4:1: warning: all paths through this function will call itself [-Winfinite-recursion] 4 | { | ^
-
What issue do you expect to see? From a quick look it seems this will produce an infinite recursion but that is nothing which was ever reported by Cppcheck.
-
Thanks for your report. I filed https://trac.cppcheck.net/ticket/14539 about it.
-
Yes, that is a known shortcoming. When you use a binary compiled on a Linux system (even WSL) we assume that all files are case sensitive. But that is not dependent on the system but the underlying filesystem. These issues are already tracked in the underlying simplecpp library via https://github.com/danmar/simplecpp/issues/308 and https://github.com/danmar/simplecpp/issues/309.
-
Yesm that is a known shortcoming. When you use a binary compiled on a Linux system (even WSL) we assume that all files are case sensitive. But that is not dependent on the system but the underlying filesystem. These issues are already tracked in the underlying simplecpp library via https://github.com/danmar/simplecpp/issues/308 and https://github.com/danmar/simplecpp/issues/309.
-
Thanks for your report. --include-file does not exist so I assume you meant --include=<file>. I filed https://trac.cppcheck.net/ticket/14538 about this.
-
Thanks for your report. I filed https://trac.cppcheck.net/ticket/14537 about supporting this.
-
Probably because the used AI agent doesn't support creating PRs yet...
-
This is a known issue already tracked in https://trac.cppcheck.net/ticket/13942.
-
We do not do anything with the rpath so it looks like a packaging issues that needs to be reported upstream.
-
Already tracked in https://trac.cppcheck.net/ticket/14091 but the behavior changed. We need to treat this differently. I will file tickets about that soon. A workaround for this is define it yourself -D__GLIBC_USE(x)=(0) for now.
-
Seems like you have the issue figured out already, why not open a PR at https://github.com/danmar/cppcheck/pulls?
-
Description Two unbounded recursive paths exist with no depth limit: Path 1 — Direct recursion via else if chains At lib/tokenize.cpp:6850-6852: if (tokEndNextNext->str() == "if") // do not change "else if ..." to "else { if ... }" tokEnd = simplifyAddBracesToCommand(tokEndNextNext); // ← direct self-recursion When simplifyAddBracesToCommand processes an if statement followed by else if, it recurses into itself for the next else if. For a chain of N else if clauses, this produces N stack frames....
-
john borland modified a comment on discussion Development
As someone who has written simulations for NASA the role cppcheck has always filled for us making sure our simulations are following C++ best practices. I would double check your definitions of what validation means to the FDA. A lot of times I find groups using the words verification and validation interchangeably which is a big mistake. For me verification means does the software meet it's requirements. Validation means does the software do what was actually wanted. A lot of the time I can't tell...
-
As someone who has written simulations for NASA the role cppcheck has always filled for us making sure our simulations are following C++ best practices. I would double check your definitions of what validation means to the FDA. A lot of times I find groups using the words verification and validation interchangeably which is a big mistake. For me verification means does the software meet it's requirements. Validation means does the software do what was actually wanted. A lot of the time I can't tell...
-
As someone who has written simulations for NASA the role cppcheck has always filled for us making sure our simulations are following C++ best practices. I would double check your definitions of what validation means to the FDA. A lot of times I find groups using the words verification and validation interchangeably which is a big mistake. For me verification means does the software meet it's requirements. Validation means does the software do what was actually wanted. A lot of the time I can't tell...
-
Prarthana B S posted a comment on discussion Development
Hi , I am planning to use Cppcheck as the static analysis tool for C++ code in our project. Since our product will be going through FDA certification, one of the key requirements is that any software tool used in the development process must be validated. Before proceeding further, I wanted to check if validation support or documentation for Cppcheck is available. Specifically: Does Cppcheck provide any formal tool validation package or certification artifacts? Is there any existing guidance or support...
-
at992 posted a comment on discussion General Discussion
Neat, thank you!
-
If ptr is NULL in main(), the while loop is not entered, and the pointer will be dereferenced. So the warning seems correct to me.
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14487
-
Simple reproduction: // cppcheck --enable=style --inconclusive a.c #define dbgMsg(msg,...) int main(int argc, char** argv) { if (1 == argc) { dbgMsg("No arguments.\n"); } else { dbgMsg("First argument is %s.\n", argv[1]); } return 0; } Deleting both of the calls to the dbgMsg macro silences the error. That is: two identical empty branches don't report a duplicateBranch error, but two branches that behave as empty after passing through the pre-processor do report that error. (In the real code, dbgMsg()...
-
Gleb Plekhotko posted a comment on discussion Development
Hello to community! I'm not sure this particular case worth to be included into the cppcheck, but still reporting it. Here is the simplified peace of code: int *ptr; int main(void) { if (ptr != NULL) { while (1); } printf("%d", *ptr); } For this case, cppcheck reports the nullPointerRedundantCheck id, considering, as far as I understand, that there is a chance to dereference the null pointer. Though it is impossible, as the program gets stuck in the eternal while loop. This is not a typical scenario...
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14477
-
When I ran the example below it didn't take very long. This is built off of latest. system76-pc:~/Test$ time ./cppcheck/Build/bin/cppcheck check=all ./uncrustify/src/indent.cpp Checking uncrustify/src/indent.cpp ... Checking uncrustify/src/indent.cpp: HAVE_INTTYPES_H=HAVE_INTTYPES_H... Checking uncrustify/src/indent.cpp: WIN32=WIN32... Checking uncrustify/src/indent.cpp: WIN32=WIN32;QNXNTO=QNXNTO... real 0m18.128s user 0m18.100s sys 0m0.016s system76-pc:~/Test$
-
Mike DeKoker posted a comment on discussion Development
Hello cppcheck folk, I have some C++20 code that is accused of containing a syntax error: template<std::uint16_t... Values> consteval auto make_flags() -> std::uint16_t { return (std::uint16_t{0} | ... | Values); } The above results in the following error: error: Syntax Error: AST broken, binary operator '|' doesn't have two operands. [internalAstError] Sample usage: #include <cstdint> template<std::uint16_t... Values> consteval auto make_flags() -> std::uint16_t { return (std::uint16_t{0} | ......
-
This might be related to compiling with C++17 or higher. Have you tried main branch?
-
Guy Maurel posted a comment on discussion Development
Thanks
-
daca seems to be down again, it would be nice to be able to check for crashes.
-
I would like to start preparations for the Cppcheck-2.20 release. The handling of Polyspace suppressions is needed in a customer trial. I suggest that we focus more on fixing bugs and testing in the coming weeks. Avoid adding complex features.
-
I often use Flame Graphsto track down performance issues. It has been some time since I have profiled cppcheck. Last time I looked at it some of the valueflow functions could escalate run time. I wasn't smart enough to figure out any useful ways of dealing with it back then. On linux there is a tool called perf top I can often use to get I high level view for performance offenders. Then there is GDB if I really need to break in to see if a program is stuck.
-
There are lots of if conditions in that file. cppcheck is known to have performance issues on such code, see e.g. https://trac.cppcheck.net/ticket/11262 So it's probably not a real hang that you are seeing, but an extremely long execution time.
-
Hello! I am the maintainer of https://github.com/uncrustify/uncrustify I try to use cppcheck with our sources. At least one source file produces a "infinite loop" : https://github.com/uncrustify/uncrustify/src/indent.cpp What shall I do to find out where is the bug? Which tools may I use for that. Thanks for any hint guy
-
graham.reeds modified a comment on discussion General Discussion
In my CMake file I download 2.19 and build it. However there are errors in compilation. The first states: C:\dev\repos\MyApp\build_deps\cppcheck-src\lib\cppcheck.cpp(880,36): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'simplecpp::Toke nList' [C:\dev\repos\MyApp\build_deps\cppcheck-build\lib\cppcheck-core.vcxproj]</function-style-cast> That line is return simplecpp::TokenList{data, size, files, file.spath(), outputList}; Looking in tokenlist.h I can see there is...
-
In my CMake file I download 2.19 and build it. However there are errors in compilation. The first states: C:\dev\repos\MyApp\build_deps\cppcheck-src\lib\cppcheck.cpp(880,36): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'simplecpp::Toke nList' [C:\dev\repos\MyApp\build_deps\cppcheck-build\lib\cppcheck-core.vcxproj]</function-style-cast> That line is return simplecpp::TokenList{data, size, files, file.spath(), outputList}; Looking in tokenlist.h I can see there is...
-
In my CMake file I download 2.19 and build it. However there are errors in compilation. The first states: C:\dev\repos\MyApp\build_deps\cppcheck-src\lib\cppcheck.cpp(880,36): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'simplecpp::Toke nList' [C:\dev\repos\MyApp\build_deps\cppcheck-build\lib\cppcheck-core.vcxproj]</function-style-cast> That line is return simplecpp::TokenList{data, size, files, file.spath(), outputList}; Looking in tokenlist.h I can see there is...
-
vix posted a comment on discussion General Discussion
cppcheck signals the warning Parameter 'callbackData' can be declared as pointer to const when the implementation of the fuction allows the const-qualification of the parameter. This is right. Sometimes the signature of the function is imposed by something else. As an example it's the callback of something and the parameter callbackData is not const in the required signature. Is there a way for me to mark in the soruce code that the cppcheck warning should be skipped for this parameter?
-
DougCube modified a comment on discussion General Discussion
This seems to be a false positive: (using 2.19.0) vector<int> vec; ... for(auto it = vec.begin(); it != vec.end();) { ... do { ... if(++it == vec.end()) break; } while(*it == 123); ... } warning: Either the condition 'it!=prev.end()' is redundant or there is possible dereference of an invalid iterator: it. [derefInvalidIteratorRedundantCheck] } while(it == 123); ^note: Assuming that condition 'it!=prev.end()' is not redundant for(auto it = vec.begin(); it != vec.end();) { ^note: Dereference of an...
-
Marcus Gigandet modified a comment on discussion General Discussion
Ignore this post. Accidental duplicate
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14443
-
This seems to be a false positive: (using 2.19.0) vector<int> vec; ... for(auto it = vec.begin(); it != vec.end();) { ... do { ... if(++it == vec.end()) break; } while(*it == 123); ... } warning: Either the condition 'it!=prev.end()' is redundant or there is possible dereference of an invalid iterator: it. [derefInvalidIteratorRedundantCheck] } while(it == 123); ^note: Assuming that condition 'it!=prev.end()' is not redundant for(auto it = vec.begin(); it != vec.end();) { ^note: Dereference of an...
-
I switched to version 2.19.0 and this issue is fixed.
-
It looks like I was running a much older version (v2.13.0 from 2023) because that is what Ubuntu apt install gives currently. But I have now manually installed v2.19.0 and this issue is fixed.
-
I think this is a false positive. template <typename T> constexpr T func(const T n) { if constexpr(std::is_signed_v<T>) if(n < 0) throw out_of_range(" n < 0 not allowed!"); ... } style: Checking if unsigned expression 'n' is less than zero. [unsignedLessThanZero] if(n < 0) throw out_of_range("n < 0 not allowed!"); -Doug
-
2.13.0
-
I think this is a false positive. class Foo { static constexpr size_t DEPTH = 4; std::array<T, DEPTH+1> arr; [[noreturn]] my_exit() { exit(1); } public: const T* func(const unsigned int n) const { if(n > DEPTH) my_exit(); return &arr[n]; } } warning: Either the condition 'n>DEPTH' is redundant or 'n' can have the value 4. Expression 'arr[n]' cause access out of bounds. [containerOutOfBounds] return &arr[n]; ^ There might also be a typo in the error message as here the array index can range from 0...
-
Hello, I've just upgrade a codebase using cppcheck 2.10 to 2.17.1 and then 2.19.1 and have run into an error that I haven't be able to solve, but I have identified the root cause. Consider the following code: typedef struct MyStruct { float thing; } MyStruct_t; static MyStruct_t myArray[sizeof(MyStruct_t)]; When evaluated on version 2.17.1 or higher (tested 2.17.1, 2.19, 2.19.1), it gives the following error: src\demo.c:6:26: error: Because of missing configuration, misra checking is incomplete....
-
Hello, I've just upgraded a codebase using cppcheck 2.10 to 2.17.1 and then 2.19.1 and have run into an error that I haven't be able to solve, but I have identified the root cause. Consider the following code: typedef struct MyStruct { float thing; } MyStruct_t; static MyStruct_t myArray[sizeof(MyStruct_t)]; When evaluated on version 2.17.1 or higher (tested 2.17.1, 2.19, 2.19.1), it gives the following error: src\demo.c:6:26: error: Because of missing configuration, misra checking is incomplete....
-
I can't reproduce this, which version are you using? Also, please add ~~~ around code.
-
Should be covered by https://trac.cppcheck.net/ticket/12387
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14431
-
Adel Mamin posted a comment on discussion General Discussion
> cppcheck --version Cppcheck 2.18.3 File test.c: struct foo { int foo; }; struct bar { struct foo foo; }; struct baz { struct bar bar; }; int main(void) { struct baz baz = {.bar = {.foo = {.foo = 1}}}; return 0; } The error: > cppcheck test.c Checking test.c ... test.c:14:34: error: Expression '.foo={.foo=1}' depends on order of evaluation of side effects [unknownEvaluationOrder] struct baz baz = {.bar = {.foo = {.foo = 1}}}; ^
-
I think this is a false positive. class Foo { static constexpr size_t DEPTH = 4; std::array<t, depth+1=""> arr;</t,> [[noreturn]] my_exit() { exit(1); } public: const T* func(const unsigned int n) const { if(n > DEPTH) my_exit(); return &arr[n]; } } warning: Either the condition 'n>DEPTH' is redundant or 'n' can have the value 4. Expression 'arr[n]' cause access out of bounds. [containerOutOfBounds] return &arr[n]; ^ There might also be a typo in the error message as here the array index can range...
-
I think this is a false positive. template <typename t=""> constexpr T func(const T n) { if constexpr(std::is_signed_v<t>) if(n < 0) throw out_of_range(" n < 0 not allowed!"); ... }</t></typename> style: Checking if unsigned expression 'n' is less than zero. [unsignedLessThanZero] if(n < 0) throw out_of_range("n < 0 not allowed!"); -Doug
1 >
