Run with --enable=warning to see that your classes have POD members that are uninitialized. I see these on an older version of quazip, but it looks like the same problem exists in the current version (from browsing the code). POD members are not initialized to zero in a class unless they are explicitly initialized, so in a release build on Windows, you'll get POD members filled with junk.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't seem to have the warning parameter. Available IDs are style, performance, portability, information, unusedFunction and missingInclude. Which version of cppcheck do you use?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using the latest version. If you are on ubuntu and just did apt-get for cppcheck, you can get one that is up to 3 years old. Latest is 1.68 and you really want to use the latest because they improve the checks all the time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, did that, still got only few minor style and performance warnings. Well, I did get some uninitialized members, but all of them inside qhash.h, which is kind of outside my jurisdiction.
I am also a bit surprised that you have found uninitialized members somewhere, because I am quite picky about that sort of thing. The only thing that comes to mind are constructorless C-style structures like QuaZipFileInfo (in fact, I can't think of any other). But those are initialized by passing pointers to them to some functions anyway. Which is kind of bad design, but I can't just change it right now because of the compatibility issues. It should not cause any problems, though, unless someone creates such a structure, and then starts to use it without ever calling any function to fill it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well cool, perhaps you fixed them in the latest version of the library. I was seeing these:
quazip-0.2.3\quazip\quazipfile.cpp(37): warning : uninitMemberVar Member variable 'QuaZipFile::caseSensitivity' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(37): warning : uninitMemberVar Member variable 'QuaZipFile::raw' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(42): warning : uninitMemberVar Member variable 'QuaZipFile::caseSensitivity' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(42): warning : uninitMemberVar Member variable 'QuaZipFile::raw' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(47): warning : uninitMemberVar Member variable 'QuaZipFile::caseSensitivity' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(47): warning : uninitMemberVar Member variable 'QuaZipFile::raw' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(54): warning : uninitMemberVar Member variable 'QuaZipFile::raw' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(64): warning : uninitMemberVar Member variable 'QuaZipFile::caseSensitivity' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(64): warning : uninitMemberVar Member variable 'QuaZipFile::raw' is not initialized in the constructor.
I think you've replaced QuaZipFile with QuaZipFileInfo from what I was seeing when browsing the code. If you think these are false positives, you can suppress then with inline comments before the offending line.
Thanks again for the library.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, these... I totally forgot about them. These were initially in QuaZipFile, but then got moved to the pimpl class. Since it is only used internally, I wasn't too careful about it. The same goes for QuaZipPrivate, I guess.
The problem is, cppcheck doesn't seem to detect it anyway. I'm using the latest cppcheck (1.68), tried even --enable=all, but all I get is the lack of the copy constructor for the pimpl classes (OK, good thing to disable copying explicitly) and a weird message about the member q being initialized with itself, even though it is actually initialized by the formal parameter with the same name.
I'll go over the pimple classes and add initialization where necessary.
As for QuaZipFileInfo, it's an entirely different thing. That's one of the C-style structs that don't even have constructors. These aren't exactly false positives, it's just I don't want to break the ABI by fixing them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just did cppcheck -f ., but it only printed out a few possible null pointers, and even that outside of QuaZIP, in Minizip.
Which options do you suggest to use?
Run with --enable=warning to see that your classes have POD members that are uninitialized. I see these on an older version of quazip, but it looks like the same problem exists in the current version (from browsing the code). POD members are not initialized to zero in a class unless they are explicitly initialized, so in a release build on Windows, you'll get POD members filled with junk.
and Thanks for the library :)
I don't seem to have the warning parameter. Available IDs are style, performance, portability, information, unusedFunction and missingInclude. Which version of cppcheck do you use?
I'm using the latest version. If you are on ubuntu and just did apt-get for cppcheck, you can get one that is up to 3 years old. Latest is 1.68 and you really want to use the latest because they improve the checks all the time.
OK, did that, still got only few minor style and performance warnings. Well, I did get some uninitialized members, but all of them inside qhash.h, which is kind of outside my jurisdiction.
I am also a bit surprised that you have found uninitialized members somewhere, because I am quite picky about that sort of thing. The only thing that comes to mind are constructorless C-style structures like QuaZipFileInfo (in fact, I can't think of any other). But those are initialized by passing pointers to them to some functions anyway. Which is kind of bad design, but I can't just change it right now because of the compatibility issues. It should not cause any problems, though, unless someone creates such a structure, and then starts to use it without ever calling any function to fill it.
Well cool, perhaps you fixed them in the latest version of the library. I was seeing these:
quazip-0.2.3\quazip\quazipfile.cpp(37): warning : uninitMemberVar Member variable 'QuaZipFile::caseSensitivity' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(37): warning : uninitMemberVar Member variable 'QuaZipFile::raw' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(42): warning : uninitMemberVar Member variable 'QuaZipFile::caseSensitivity' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(42): warning : uninitMemberVar Member variable 'QuaZipFile::raw' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(47): warning : uninitMemberVar Member variable 'QuaZipFile::caseSensitivity' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(47): warning : uninitMemberVar Member variable 'QuaZipFile::raw' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(54): warning : uninitMemberVar Member variable 'QuaZipFile::raw' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(64): warning : uninitMemberVar Member variable 'QuaZipFile::caseSensitivity' is not initialized in the constructor.
quazip-0.2.3\quazip\quazipfile.cpp(64): warning : uninitMemberVar Member variable 'QuaZipFile::raw' is not initialized in the constructor.
I think you've replaced QuaZipFile with QuaZipFileInfo from what I was seeing when browsing the code. If you think these are false positives, you can suppress then with inline comments before the offending line.
Thanks again for the library.
Oh, these... I totally forgot about them. These were initially in QuaZipFile, but then got moved to the pimpl class. Since it is only used internally, I wasn't too careful about it. The same goes for QuaZipPrivate, I guess.
The problem is, cppcheck doesn't seem to detect it anyway. I'm using the latest cppcheck (1.68), tried even --enable=all, but all I get is the lack of the copy constructor for the pimpl classes (OK, good thing to disable copying explicitly) and a weird message about the member q being initialized with itself, even though it is actually initialized by the formal parameter with the same name.
I'll go over the pimple classes and add initialization where necessary.
As for QuaZipFileInfo, it's an entirely different thing. That's one of the C-style structs that don't even have constructors. These aren't exactly false positives, it's just I don't want to break the ABI by fixing them.