Re: [PATCH] [12/11/10] Fix invalid format warnings on Windows

[Jeff Law <jeffreyalaw@gmail.com>]

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