[Bug c/95130] New: GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[Bug c/95130] New: GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[martin at martin dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

            Bug ID: 95130
           Summary: GCC ignoring attribute(format(gnu_printf)) on printf
                    in mingw
           Product: gcc
           Version: 9.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: martin at martin dot st
  Target Milestone: ---

Since a long time (GCC 4.4?) GCC does support annotating functions with either
the format attribute "gnu_printf" or "ms_printf" to distinguish between
different format string interpretations.

However, it seems like the attribute is ignored for the "printf" symbol;
regardless what the function declaration says, GCC treats it as "ms_printf".
This has become an issue now that mingw-w64 supports using the UCRT instead of
msvcrt.dll, and in this case the stdio functions are declared with the
gnu_printf attribute, and inttypes.h uses the same format specifiers as in GNU
mode.

A reproducible example of the problem:

$ cat format.c
__attribute__((__format__ (gnu_printf, 1, 2))) int printf (const char
*__format, ...);
__attribute__((__format__ (gnu_printf, 1, 2))) int othername (const char
*__format, ...); 

void function(void) {
    long long unsigned x = 42;
    othername("%llu\n", x);
    printf("%llu\n", x);
}
$ x86_64-w64-mingw32-gcc -c -Wformat format.c 
format.c: In function 'function':
format.c:7:15: warning: unknown conversion type character 'l' in format
[-Wformat=] 
    7 |     printf("%llu\n", x); 
      |               ^
format.c:7:12: warning: too many arguments for format [-Wformat-extra-args]
    7 |     printf("%llu\n", x);
      |            ^~~~~~~~


Note how both functions, printf and othername, are declare with identical
gnu_printf format attributes - GCC does take this into account for "othername"
and doesn't produce a warning, but GCC seems to disregard the attribute in the
printf declaration and behave as if it was declared as ms_printf.

If the printf function declaration is changed into a static inline function,
the actual attribute used is honored though.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
See bug 92292.  The extra attribute isn't ignored, it simply means the 
function has multiple format attributes, which is valid, but should 
probably be special-cased for this case of built-in functions.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

Tomas Kalibera <tomas.kalibera at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tomas.kalibera at gmail dot com

--- Comment #2 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
My apologies if this is obvious, but please let me note this issue means that
one cannot print(f) a 64-bit integer without a compile-time warning with UCRT
on Windows. It would be a great help if this could somehow be fixed.

In the example below, lines (1) and (2) work without a warning with MSVCRT.
But, all three issue a warning with UCRT.

#include <inttypes.h>
#include <stdio.h>

int main(int argc, char **argv) {
  long long unsigned x = 112;

  printf("Hello %"PRIu64"\n", x); // 1
  printf("Hello %I64u\n", x);     // 2
  printf("Hello %llu\n", x);      // 3
  return 0;
}

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #3 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
Created attachment 52007
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52007&action=edit
Patch to ignore first format for builtins that have more than one

This patch for 10.3.0 instructs gcc to ignore the first format attribute for
functions that have multiple format attributes and are builtins with a format
attribute added by GCC.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #4 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
Created attachment 52008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52008&action=edit
Example from comment 2

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #5 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #1)
> See bug 92292.  The extra attribute isn't ignored, it simply means the 
> function has multiple format attributes, which is valid, but should 
> probably be special-cased for this case of built-in functions.

I've added a draft of a patch to address the issue in the suggested way. I've
tested it in gcc 10.3.0 on the example from comment 2 (also attached). With the
patch applied, only line (2) gets a warning, as it should.

When deciding whether to emit a format warning for a function with multiple
format attributes, it skips the first format in case it is a builtin known to
have a format added by gcc. Please let me know if you have any advice how to
improve (thanks to Martin Liska for helping me with identifying the builtins),
or indeed feel free to adjust and add your way. Fixing this would help the R
community or anyone else who uses GCC with UCRT.

Thanks,
Tomas

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

LIU Hao <lh_mouse at 126 dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lh_mouse at 126 dot com

--- Comment #6 from LIU Hao <lh_mouse at 126 dot com> ---
This patch no longer applies to trunk. Would you please update it?

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #7 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches
mailing list in May:

https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html

The patches still apply to current 10,11,12 and trunk. Please see the email
linked above for more information.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[martin at martin dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #8 from Martin Storsjö <martin at martin dot st> ---
(In reply to Tomas Kalibera from comment #7)
> I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches
> mailing list in May:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html
> 
> The patches still apply to current 10,11,12 and trunk. Please see the email
> linked above for more information.

Did you notice the review comment in July,
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597777.html?

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #9 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
(In reply to Martin Storsjö from comment #8)
> (In reply to Tomas Kalibera from comment #7)
> > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches
> > mailing list in May:
> > 
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html
> > 
> > The patches still apply to current 10,11,12 and trunk. Please see the email
> > linked above for more information.
> 
> Did you notice the review comment in July,
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597777.html?

Ah, thanks, I missed it (as I wasn't on the to/cc).

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #10 from LIU Hao <lh_mouse at 126 dot com> ---
(In reply to Tomas Kalibera from comment #7)
> I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches
> mailing list in May:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html
> 
> The patches still apply to current 10,11,12 and trunk. Please see the email
> linked above for more information.


Thanks for the patch. Updated locally. I will test it against trunk as soon as
I get a little time.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #11 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
(In reply to LIU Hao from comment #10)
> (In reply to Tomas Kalibera from comment #7)
> > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches
> > mailing list in May:
> > 
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html
> > 
> > The patches still apply to current 10,11,12 and trunk. Please see the email
> > linked above for more information.
> 
> 
> Thanks for the patch. Updated locally. I will test it against trunk as soon
> as I get a little time.

Thanks. Re Jeff's comment from the mailing list:

> 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?

I didn't find any elegant way to find out whether a format attribute is a
built-in attribute in check_function_format(). So unless I overlooked something
(which is very much possible), it would make the patch more intrusive.

handle_format_attribute() has that information in flags (ATTR_FLAG_BUILT_IN).
Maybe handle_format_attribute() could add the flags (or only a boolean whether
it is a builtin attribute) to the attribute tree, so that
check_function_format() can access it, e.g. similarly to how no_sanitize does
it. Would this be better? And if so, is there a recommended place in the format
attribute tree where it should be added to?

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

Tomas Kalibera <tomas.kalibera at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #52007|0                           |1
        is obsolete|                            |

--- Comment #12 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
Created attachment 53778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53778&action=edit
Draft patch to ignore built-in format attribute for a builtin, if there is
another one

This is a draft of an alternative patch, which addresses the concern that in
theory the built in format attribute may not be the first one in the list of
attributes of a built-in function. This patch puts attribute flags inside
TREE_PURPOSE of the attribute, so that it can be checked later whether it is a
built in attribute. I am not sure whether this is legal, but it should be easy
to update it to store the flags somewhere else, if needed.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #13 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
Another instance of this problem is %z (to print size_t). It is supported by
UCRT, but the GCC's Microsoft format warns, because it wasn't supported with
MSVCRT (seen with GCC 12.2).

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[alvinhochun at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

Alvin Wong <alvinhochun at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alvinhochun at gmail dot com

--- Comment #14 from Alvin Wong <alvinhochun at gmail dot com> ---
`strftime` is another case that's affected. UCRT supports C99 formats (e.g. %F,
%T) but GCC warns because of the hardcoded built-in ms_strftime format
attribute, even though mingw-w64 has specified gnu_strftime.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tanksherman27 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

Julian Waters <tanksherman27 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tanksherman27 at gmail dot com

--- Comment #15 from Julian Waters <tanksherman27 at gmail dot com> ---
It seems like the patch also doesn't fix the strftime case too, strangely
enough. gcc with that patch applied still causes a compilation failure in the
Windows JDK when encountering strftime with the %T specifier

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #16 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
(In reply to Julian Waters from comment #15)
> It seems like the patch also doesn't fix the strftime case too, strangely
> enough. gcc with that patch applied still causes a compilation failure in
> the Windows JDK when encountering strftime with the %T specifier

Given that this bug hasn't attracted enough attention to get fixed, perhaps you
could try reporting this as a wish for improvement of the ms_strftime format
(msformat-c.c, ms_time_char_table): probably it should support %T.

I don't easily see why the patch doesn't help with %T in strftime. In MinGW-W64
10, strftime doesn't seem to have a format attribute at all, so the patch
couldn't help. But in MinGW-W64 11, the gnu_strftime format attribute is
present.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #17 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
(In reply to Tomas Kalibera from comment #16)
> (In reply to Julian Waters from comment #15)
> > It seems like the patch also doesn't fix the strftime case too, strangely
> > enough. gcc with that patch applied still causes a compilation failure in
> > the Windows JDK when encountering strftime with the %T specifier
> 
>
> I don't easily see why the patch doesn't help with %T in strftime. In
> MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so
> the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format
> attribute is present.

The older version of the patch I use with gcc 12 doesn't seem to be helping
with %T, but the newer one (patch_master.diff) helps with %T on the current gcc
master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with MinGW-W64
11.0.1.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tanksherman27 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #18 from Julian Waters <tanksherman27 at gmail dot com> ---
That's great news! With regards to this patch, I'm fairly certain you have to
proactively send it to gcc-patches mailing list for it to be merged; No gcc
committer has the time to look for this issue and commit it. I also think it's
probably time for ms_printf to formally recognize ISO C format specifiers once
and for all, too

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tanksherman27 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #19 from Julian Waters <tanksherman27 at gmail dot com> ---
(In reply to Tomas Kalibera from comment #17)
> (In reply to Tomas Kalibera from comment #16)
> > (In reply to Julian Waters from comment #15)
> > > It seems like the patch also doesn't fix the strftime case too, strangely
> > > enough. gcc with that patch applied still causes a compilation failure in
> > > the Windows JDK when encountering strftime with the %T specifier
> > 
> >
> > I don't easily see why the patch doesn't help with %T in strftime. In
> > MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so
> > the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format
> > attribute is present.
> 
> The older version of the patch I use with gcc 12 doesn't seem to be helping
> with %T, but the newer one (patch_master.diff) helps with %T on the current
> gcc master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with
> MinGW-W64 11.0.1.

If I may ask, could I have the link to patch_master.diff?

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #20 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
(In reply to Julian Waters from comment #19)
> (In reply to Tomas Kalibera from comment #17)
> > (In reply to Tomas Kalibera from comment #16)
> > > (In reply to Julian Waters from comment #15)
> > > > It seems like the patch also doesn't fix the strftime case too, strangely
> > > > enough. gcc with that patch applied still causes a compilation failure in
> > > > the Windows JDK when encountering strftime with the %T specifier
> > > 
> > >
> > > I don't easily see why the patch doesn't help with %T in strftime. In
> > > MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so
> > > the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format
> > > attribute is present.
> > 
> > The older version of the patch I use with gcc 12 doesn't seem to be helping
> > with %T, but the newer one (patch_master.diff) helps with %T on the current
> > gcc master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with
> > MinGW-W64 11.0.1.
> 
> If I may ask, could I have the link to patch_master.diff?

It is one of the attachments of this report,
https://gcc.gnu.org/bugzilla/attachment.cgi?id=53778

This patch has not been reviewed. I am not an expert on GCC internals and I
cannot guarantee that adding meta-data this way to the AST is safe. So please
use with care.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Yong <jyong@gcc.gnu.org>:

https://gcc.gnu.org/g:966f3c134bb4802ac7ba0517de4e8e3f6384cfa3

commit r14-3334-g966f3c134bb4802ac7ba0517de4e8e3f6384cfa3
Author: Tomas Kalibera <tomas.kalibera@gmail.com>
Date:   Sun Aug 20 02:16:16 2023 +0000

    Fix format attribute for printf

    Since a long time (GCC 4.4?) GCC does support annotating functions
    with either the format attribute "gnu_printf" or "ms_printf" to
    distinguish between different format string interpretations.

    However, it seems like the attribute is ignored for the "printf"
    symbol; regardless what the function declaration says, GCC treats
    it as "ms_printf". This has become an issue now that mingw-w64
    supports using the UCRT instead of msvcrt.dll, and in this case
    the stdio functions are declared with the gnu_printf attribute,
    and inttypes.h uses the same format specifiers as in GNU mode.

    A reproducible example of the problem:

    $ cat format.c
    __attribute__((__format__ (gnu_printf, 1, 2))) int printf (const char
*__format, ...);
    __attribute__((__format__ (gnu_printf, 1, 2))) int othername (const char
*__format, ...);

    void function(void) {
        long long unsigned x = 42;
        othername("%llu\n", x);
        printf("%llu\n", x);
    }
    $ x86_64-w64-mingw32-gcc -c -Wformat format.c
    format.c: In function 'function':
    format.c:7:15: warning: unknown conversion type character 'l' in format
[-Wformat=]
        7 |     printf("%llu\n", x);
          |               ^
    format.c:7:12: warning: too many arguments for format [-Wformat-extra-args]
        7 |     printf("%llu\n", x);
          |            ^~~~~~~~

    Note how both functions, printf and othername, are declare with
    identical gnu_printf format attributes - GCC does take this into
    account for "othername" and doesn't produce a warning, but GCC
    seems to disregard the attribute in the printf declaration and
    behave as if it was declared as ms_printf.

    If the printf function declaration is changed into a static inline
    function, the actual attribute used is honored though.

    gcc/c-family/ChangeLog:

            PR c/95130
            * c-format.cc: skip default format for printf symbol if
            explicitly declared by prototype.

    Signed-off-by: Tomas Kalibera <tomas.kalibera@gmail.com>
    Signed-off-by: Jonathan Yong <10walls@gmail.com>

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #22 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
(In reply to CVS Commits from comment #21)
> The master branch has been updated by Jonathan Yong <jyong@gcc.gnu.org>:
> 
> https://gcc.gnu.org/g:966f3c134bb4802ac7ba0517de4e8e3f6384cfa3
> 
> commit r14-3334-g966f3c134bb4802ac7ba0517de4e8e3f6384cfa3
> Author: Tomas Kalibera <tomas.kalibera@gmail.com>
> Date:   Sun Aug 20 02:16:16 2023 +0000
> 
>     Fix format attribute for printf
>     
>     Since a long time (GCC 4.4?) GCC does support annotating functions
>     with either the format attribute "gnu_printf" or "ms_printf" to
>     distinguish between different format string interpretations.
>     
>     However, it seems like the attribute is ignored for the "printf"
>     symbol; regardless what the function declaration says, GCC treats
>     it as "ms_printf". This has become an issue now that mingw-w64
>     supports using the UCRT instead of msvcrt.dll, and in this case
>     the stdio functions are declared with the gnu_printf attribute,
>     and inttypes.h uses the same format specifiers as in GNU mode.
>     
>     A reproducible example of the problem:
>     
>     $ cat format.c
>     __attribute__((__format__ (gnu_printf, 1, 2))) int printf (const char
> *__format, ...);
>     __attribute__((__format__ (gnu_printf, 1, 2))) int othername (const char
> *__format, ...);
>     
>     void function(void) {
>         long long unsigned x = 42;
>         othername("%llu\n", x);
>         printf("%llu\n", x);
>     }
>     $ x86_64-w64-mingw32-gcc -c -Wformat format.c
>     format.c: In function 'function':
>     format.c:7:15: warning: unknown conversion type character 'l' in format
> [-Wformat=]
>         7 |     printf("%llu\n", x);
>           |               ^
>     format.c:7:12: warning: too many arguments for format
> [-Wformat-extra-args]
>         7 |     printf("%llu\n", x);
>           |            ^~~~~~~~
>     
>     Note how both functions, printf and othername, are declare with
>     identical gnu_printf format attributes - GCC does take this into
>     account for "othername" and doesn't produce a warning, but GCC
>     seems to disregard the attribute in the printf declaration and
>     behave as if it was declared as ms_printf.
>     
>     If the printf function declaration is changed into a static inline
>     function, the actual attribute used is honored though.
>     
>     gcc/c-family/ChangeLog:
>     
>             PR c/95130
>             * c-format.cc: skip default format for printf symbol if
>             explicitly declared by prototype.
>     
>     Signed-off-by: Tomas Kalibera <tomas.kalibera@gmail.com>
>     Signed-off-by: Jonathan Yong <10walls@gmail.com>

Great, thanks a lot for finishing and adding this,
Tomas

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #23 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note since MSVC 2015 runtime, printf has support %ll so ms_printf should be
fixed to incldue that.

https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=msvc-140

I think for GCC 15, we should just update ms_printf to the 2015 version of what
is supported ...

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #24 from LIU Hao <lh_mouse at 126 dot com> ---
(In reply to Andrew Pinski from comment #23)
> Note since MSVC 2015 runtime, printf has support %ll so ms_printf should be
> fixed to incldue that.
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification-
> syntax-printf-and-wprintf-functions?view=msvc-140
> 
> I think for GCC 15, we should just update ms_printf to the 2015 version of
> what is supported ...

`%ll` has been supported since c51f1e7427e6a5ae2a6d82b5a790df77a3adc99a.

`%L` (for floating-point specifiers) is not compatible between `ms_printf` and
`gnu_printf`.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[martin at martin dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #25 from Martin Storsjö <martin at martin dot st> ---
(In reply to Andrew Pinski from comment #23)
> Note since MSVC 2015 runtime, printf has support %ll so ms_printf should be
> fixed to incldue that.
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification-
> syntax-printf-and-wprintf-functions?view=msvc-140
> 
> I think for GCC 15, we should just update ms_printf to the 2015 version of
> what is supported ...

As long as GCC links against msvcrt.dll, distributed with the OS, the time
since it's supported in MSVC doesn't affect things much though.

But as Liu Hao noted, we already do support %lld in ms_printf since
c51f1e7427e6a5ae2a6d82b5a790df77a3adc99a, since it apparently was supported in
the OS provided msvcrt.dll since a number of versions anyway.

(In reply to LIU Hao from comment #24)
> `%L` (for floating-point specifiers) is not compatible between `ms_printf`
> and `gnu_printf`.

We do use gnu_printf for the UCRT printf functions (which is what MSVC ships
since 2015) though, see e.g.
https://github.com/mingw-w64/mingw-w64/commit/8565cdb729b96f1122b1e9c490a7baba7b788f18.

But since the change in c51f1e7427e6a5ae2a6d82b5a790df77a3adc99a (released in
GCC 12 already), we probably don't need this any longer. So I think it might be
more correct to revert to ms_printf for UCRT, at least for GCC >= 12 - what do
you think?

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #26 from LIU Hao <lh_mouse at 126 dot com> ---
(In reply to Martin Storsjö from comment #25)
> But since the change in c51f1e7427e6a5ae2a6d82b5a790df77a3adc99a (released
> in GCC 12 already), we probably don't need this any longer. So I think it
> might be more correct to revert to ms_printf for UCRT, at least for GCC >=
> 12 - what do you think?

Yes, makes perfect sense.

One reason for it is the difference about `long double`, and another is that
there are GNU specifiers that MS doesn't support e.g. `%m`.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #27 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
%zu should be added to ms_printf too.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

--- Comment #28 from LIU Hao <lh_mouse at 126 dot com> ---
(In reply to Andrew Pinski from comment #27)
> %zu should be added to ms_printf too.

MSVCRT.DLL from Windows 7 does not support the `z` modifier.

It seems supported on Windows 10; however people really should prefer UCRT
there.