On 5/16/2022 5:27 AM, Tomas Kalibera via Gcc-patches wrote:
On 5/11/22 18:43, Joseph Myers wrote:
There are various coding style issues in the patch; at least missing
space
before '(' and '&&' at end of line (should be at start of line). It
will
also need to be updated for .c files having been renamed to .cc in
the GCC
source tree.
Thanks, I've fixed the formatting issue and updated the patch for
master, 12, 11 and 10. In addition to the renaming of .c to .cc files,
there was also a change in the first argument of
check_function_format. I've also removed a duplicated check for
whether fndecl was null and fixed indentation.
I've updated the patches for each version to also note that in
c51f1e7427e6a5ae2a6d82b5a790df77a3adc99a
gcc: Add `ll` and `L` length modifiers for `ms_printf`
the ms_printf format has been taught to support (not warn about)
printing the 64-bit integers using the "%ll" modifier (currently GCC
11 and newer). However, I assume there may be other differences
between the ms_printf and gnu_printf formats people might run into, so
it still makes sense to fix this not only in GCC 10, but also in newer
versions.
Furthermore, the attached patch is still needed (GCC 11, GCC 12,
master) to get rid of duplicate warnings for an incorrect format (e.g.
"%lu" used to print "unsigned long long"), when both ms_printf and
gnu_printf formats are violated (PR 92292).
I guess we're going to depend on the builtin-format always appearing
first in the chain? While it's probably true in practice, I doubt we
really want to depend on that.
Is there any sensible way to distinguish between the builtin format and
one that comes from the source?
There's a trivial formatting nit:
+ for(aa = TREE_CHAIN (a); aa; aa = TREE_CHAIN (aa))
Space between the "for" and its open paren.
But I think the big question here is whether or not we want to assume
the builtin format is always first on the chain.
jeff
