Clint Chelak

I reposted with the title here. Can someone with the authority destroy this duplicate? Sorry for the spam.

I ran into autocode that has a curious use of braces in the constructor that causes an internalAstError. I recreated the issue below. // file CppcheckCtorDefinitionError.cpp #include <cstdint> typedef std::uint8_t UInt8; typedef std::uint32_t UInt32; struct ThingWithPath { ThingWithPath(); UInt8* pFilePath; UInt32 filePathElements; }; ThingWithPath::ThingWithPath() : pFilePath{new UInt8[512]{}}, // the error occurs here with the empty "{}" filePathElements{0} {} int main() { ThingWithPath t; return...

Oh no, the title was lost, and this was supposed to be put in "Development". I'm not seeing a way to delete, edit, or move the entire post. Sorry guys. Title was "cppcheck 2.10: internalAstError in constructor initialization list"

I ran into autocode that has a curious use of braces in the constructor that causes an internalAstError. I recreated the issue below. // file CppcheckCtorDefinitionError.cpp #include <cstdint> typedef std::uint8_t UInt8; typedef std::uint32_t UInt32; struct ThingWithPath { ThingWithPath(); UInt8* pFilePath; UInt32 filePathElements; }; ThingWithPath::ThingWithPath() : pFilePath{new UInt8[512]{}}, // the error occurs here with the empty "{}" filePathElements{0} {} int main() { ThingWithPath t; return...

Thanks for the response. The solution we found was very similar, putting #ifndef CPPCHECK around those macros. It proved to create fewer false positives than commenting out the NEED_CODE exception through macros.

A More Complex Scenario: Text substitution Here is the scenario I'm truly stuck on which is not as simple as removing the function. Cppcheck has been good in sparking discussions on whether we still have plans to develop functions such as the ones above, but there are cases where I don't have a choice in removing a function. The following is an example (roughly) found in our code (I've tried to simplify it to illustrate the concern). The macro below serves as a wrapper function for an interface....

I have functions in my company code that have non-void return types but can find themselves with a runtime NEED_CODE exception to be thrown for scenarios we need to address but haven't finished the logic for. An example of an unfinished function below. int myFutureFeature() { NEED_CODE; // A macro set by our company to throw an exception with message return 0; } In these scenarios, we will trigger duplicateBreak conditions in cppcheck if we leave the return statement after the exception, and compile...

I'm attempting to create libraries for Blitz, a commonly used C++ library for multi-dimensional array arithmetic. In it, the user accesses and sets elements of an array using the operator() call. For example, // Objects are declared as such blitz::Array<int, 2> myArray; // A 2D array of no current size myArray.resize(2,2); // It is now a 2x2 myArray(1,0) = 3; // The second-column/first-row element is set to 3 The last line--myArray(1,0) = 3;--is what I was trying to configure in my blitz.cfg library....