Closed mcrha closed 7 months ago
This change will cause the wrong printf format specifier to be used in the following DEBUG_WARN call after uncompress failure.
Also, I think it would be best to use the zlib uLongf type to make it explicit that this is a variable for zlib rather than libpst, just as the casts in the call to uncompress do for Bytef.
Please add info about the commit you are fixing to the commit message:
Fixes: commit a9fb0d8c21c781e679e6e93bb24da14b620ce60d
-- bye, pabs
This change will cause the wrong printf format specifier to be used in the following DEBUG_WARN call after uncompress failure.
What do you suggest to do here, please? A cast to size_t
in the print command sounds easily doable, what do you think? Otherwise I'm not familiar with arch-dependant format specifiers in the libpst, I know about those only in glib.
I do not see a compiler warning about the formats here (the build.log-s can be accessed in koji), but it can be either the DEBUG_WARN
does not have set gcc attributes for it or it does not evaluate in the Fedora builds. I do not know.
Also, I think it would be best to use the zlib uLongf type
Interesting, I though the gcc warning uses verbatim code from the header file, but I see it expanded the macros. I did not know they have their own type for it.
Since zlib doesn't provide a define for the uLongf printf format specifier, a cast to size_t seems like the way to go.
I only found the extra type because I wasn't sure what the uncompress prototype was using, so went looking for it 😀️
Okay, I made the change, with few more type casting, even that did not produce any compiler warning.
This fixes a recent Fedora build, which failed on i686 architecture with "incompatible pointer types" error: