Sylvain Joubert

Yes, a couple years ago. But the account creation could be simpler than having to send a password hash to the maintainer so I gave up. I'll look into creating an account again. Thanks for following with the bug reports so far :-)

I'm not sure what happens. Maybe a is wrongly assigned to the inner class. Note that if Inner has a default implementation and is not forward declared, the warning still appears, as long as it is specialized afterward. ❯ cppcheck --version Cppcheck 2.11 ❯ cat test.cpp template <typename T> class Test { public: Test(); int& get() { return a; } private: struct Inner; // or struct Inner {}; int& a; }; template <> struct Test<int>::Inner { }; ❯ cppcheck --enable=style --std=c++20 test.cpp Checking test.cpp...

I know there was some recent fixes on C++20 templated lambda, so this may already be fixed. But that seems a slightly different use case, so I prefer to report it as well. $ cppcheck --version Cppcheck 2.11 $ cat test.cpp int main() { auto test = []<typename T, typename U>(int) { }; test.operator()<int, int>(42); } $ cppcheck --enable=style --std=c++20 test.cpp Checking test.cpp ... test.cpp:6:22: warning: Found suspicious operator ',', result is not used. [constStatement] test.operator()<int, int>(42);...

I also encountered a FP using reference. Not sure if it's the exact same pattern though: #include <nlohmann/json.hpp> bool check(); bool double_check(); nlohmann::json test() { nlohmann::json data; auto& elem = data["elem"]; // style: Variable 'elem' is assigned a value that is never used. [unreadVariable] if (check()) { elem = 42; } else if (double_check()) { elem = 1; } return data; } Notes: * I could not easily reduce/reproduce this without using nlohmann::json, so I don't know if this is actually...

With cppcheck 2.11 I now get some autovarInvalidDeallocation false positives that I did not get with previous versions. At least I think it is false positive since I can't reason why it would be a error and because the error message seems wrongly put together making me think this is an edge case badly handled. I can't reduce a small test case unfortunately as I don't understand exactly what trips it. But here is the "bad" message hoping it can help (the (() is particularly suspicious): Deallocation...

Updgrading to cppcheck 2.11 I know get CastIntegerToAddressAtReturn warnings on the following test code reduced from my codebase: int* nested_template_lambda_return() { auto explicitTemplate = []<typename T>() { return true; }; auto noTemplate = []() { return true; }; return nullptr; } $ cppcheck test.cpp --enable=portability Checking test.cpp ... test.cpp:5:5: portability: Returning an integer in a function with pointer return type is not portable. [CastIntegerToAddressAtReturn] return true; ^ This...

The following code: #include <string> void test(std::string const& a, std::string const& b) { if (a.empty() && b.empty()) { } else if (a.empty() == false && b.empty() == false) // False positives { } if (a.empty() && b.empty()) { } else if (!a.empty() && !b.empty()) // This is fine { } } produces the following warnings: Checking test.cpp ... test.cpp:8:22: style: Condition 'a.empty()==false' is always true [knownConditionTrueFalse] else if (a.empty() == false && b.empty() == false) ^ test.cpp:5:14:...

In Qt code, any (if not all) lines using the Q_EMIT macro: Q_EMIT mySignal(42); now trigger a shadowFunction warning like: warning: Local variable 'mySignal' shadows outer function [shadowFunction] Q_EMIT mySignal(42); I see a specific line to define the emit macro in qt.cfg (which I'm using) but nothing about Q_EMIT. I've been able to fix the issue locally by using a custom config file with the following content: <?xml version="1.0" encoding="UTF-8"?> <def format="2"> <define name="Q_EMIT" value=""/>...