On 28 Dec 2025, at 23:51, Greg Troxel via Tiff <[email protected]> wrote: > > Roger Leigh via Tiff <[email protected]> writes: > >> The warnings are split into two groups: default and extra. At the moment, >> you have to opt-in to get the extra warnings, and we enable them in the CI >> build. >> >> https://gitlab.com/rleigh/libtiff/-/blob/warning-additions5/cmake/CompilerChecks.cmake#L68 >> is the state of things after all of the proposed changes are done. >> >> We can look at making more of these the default, so long as we’re sure they >> aren’t going to erroneously warn on other systems. > > I see where you're coming from but would good to get to "always on" when > it is possible.
Absolutely, I’m not averse to it, but I might add some older compiler versions to the test matrix just to be sure it’s not going to be too problematic. If we keep them in that second “extra warnings” category, flipping the default to “ON” means we can at least allow them all to be easily turned OFF should they end up breaking the build in some situations. > >>> If there's a situation where the code is not wrong, and the compiler >>> is wrongly complaining, and there's a workaround, that should be >>> loudly annotated in the checked-in code and the commit message. And >>> probably should be raised for discussion. >> >> There’s only a single one that I’m aware of, which looks like a GCC and/or C >> standard issue. GCC isn’t technically wrong, but it’s practically wrong. >> >> This is the use of "%"PRIu16 in a format string, with a uint16_t >> argument. The variadic function promotes the value to int and then it >> complains about the signedness mismatch IIRC. Clang and MSVC are fine >> with it. I ended up switching it back to "%u" which works everywhere >> with no actual behaviour change given that PRIu16 is %u on most >> platforms anyway. You could claim the GCC behaviour is in one respect >> actually fully standards compliant, but it kind of defeats the purpose >> of the inttypes macros and is annoying, but the workaround is simple >> enough. > > If that's the only problem, that's fantastic. > > (Interesting that %u is ok, if uint16_t is promoted to int because all > values fit….) I did also have to add an (unsigned int) cast as well. E.g. https://gitlab.com/libtiff/libtiff/-/merge_requests/798/diffs?file=6dca20b855540648b3051810ade5c0f30734c768#6dca20b855540648b3051810ade5c0f30734c768_1000_1000 Looks like a GCC problem in the format-string checker given that clang does the same strict checking of matching variadic types to formats. There’s clearly nothing actually wrong, and it works fine in the other situation, so it’s likely the check could be fixed. I’ll see about making a test case to report to the GCC bug tracker. Kind regards, Roger _______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
