David Brady

Just FYI, I've just checked a recent version of cppcheck on our substantial UnrealEngine-based codebase, and found a few false positives you might not be aware of, as detailed below (note that this code won't compile though, it's just for testing cppcheck). struct TestStruct { int m; }; void SomeInitFunc(TestStruct& Test) { Test.m = 0; } //cppcheck erroneously flags this as returning local memory int* GetAddressOfStatic() { struct StaticStruct {int m;}; static StaticStruct Test{0}; return &Test.m;...

Just FYI, I've just checked a recent version of cppcheck on our substantial UnrealEngine-based codebase, and found a few false positives you might not be aware of, as detailed below (note that this code won't compile though, it's just for testing cppcheck). struct TestStruct { int m; }; void SomeInitFunc(TestStruct& Test) { Test.m = 0; } //cppcheck erroneously flags this as returning local memory int* GetAddressOfStatic() { struct StaticStruct {int m;} static StaticStruct Test{0}; return &Test.m;...

Just FYI, I've just checked a recent version of cppcheck on our substantial UnrealEngine-based codebase, and found a few false positives you might not be aware of, as detailed below (note that this code won't compile though, it's just for testing cppcheck). struct TestStruct { int m; }; void SomeInitFunc(TestStruct& Test) { Test.m = 0; } //cppcheck erroneously flags this as returning local memory bool* GetAddressOfStatic() { struct StaticStruct {int m;} static StaticStruct Test{0}; return &Test.m;...

Just wanted to say that I am seeing the same problem in the latest head. I removed the validation code in lib/tokenize.cpp (under the //garbage templates comment), and it appears to have resolved the problem for us locally (at a glance, it seemed to be just handling the case of invalid templates, but doesn't work properly). This code caused cppcheck to throw a syntax error (but oddly not in the last official release): template <> void f<std::string>(std::string const& x) {}

Actually no, that would make it so that I would never quite be sure if the file I was looking at was actually for my current run or some previous run if I failed to clean my output. I definitely wouldn't want that How about prepending a numbered directory name in front of a relative directory name in the dump file output directory (in the case of a recursive directory argument)? That would require some rather extensive changes to the code though, as the files map would likely have to change from...

I had a closer look at this today. My original proposal doesn't appear to work, as cppcheck also allows multiple file or directory arguments. So how about maybe just appending a (2) after the name if a dump file exists?

I'll see about setting up a github account. And yeah, I forgot that cppcheck allows you to check multiple files at once (I'm just using it like a compilert). Maybe if we were to mirror the relative directory location from the current working directory (or --dump-dir?), if checking a directory?

I would like the ability to specify dump file locations from the command line. I've just started using that feature at work, and it's very inconvenient having the dump files written to the source directory. I have patches that I am more than happy to share, but the bug tracker is private, and there's nobody in chat. From 4f9bb0731892ee258794adf1fe32774f1ca68f7e Mon Sep 17 00:00:00 2001 From: David Brady <classic.grey@gmail.com> Date: Thu, 2 Nov 2017 19:00:34 -0400 Subject: [PATCH] Add ability to...