public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "mikpe at it dot uu dot se" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/37768]  New: bogus warnings on x86_64-mingw32 due to attribute((format(printf))) breakage
Date: Wed, 08 Oct 2008 09:31:00 -0000	[thread overview]
Message-ID: <bug-37768-7665@http.gcc.gnu.org/bugzilla/> (raw)

When gcc is configured to generate code for x86_64-pc-mingw32, that is MinGW
for 64-bit Windows, attribute((format(printf))) is redefined by the backend to
be compatible with MSVC's runtime library, which differs significantly from
C99.

This is fine for calls that link to MSVC's library, but it breaks code that
uses private implementations of C99-compliant formatting routines, because the
backend redefines ALL uses of attribute((format(printf))) to mean MSVC's printf
not C99. The result is that C99-compliant code gets stray warnings and
inadequate printf format checking on x86_64-pc-mingw32.

The program below illustrates the issue. It declares a private C99-compliant
snprintf() implementation and invokes it with "%zu" and "%llx" formats. This
triggers the following bogus warnings on x86_64-pc-mingw32:

> x86_64-pc-mingw32-gcc -std=c99 -O -Wall -c badwarning.c
badwarning.c: In function 'main':
badwarning.c:16: warning: unknown conversion type character 'z' in format
badwarning.c:16: warning: unknown conversion type character 'l' in format
badwarning.c:16: warning: too many arguments for format

What I think the backend should do is to implement an "msprintf" format type,
and then Mingw-w64 should declare printf() et al using that not plain "printf".

/* badwarning.c */
#include <stddef.h>
#include <stdarg.h>

int  __attribute__((format(printf, 3, 4)))
    my_snprintf(char *buf, size_t n, const char *fmt, ...)
{
    /* invoke C99 compliant private vsnprintf() here */
    return 0;
}

int main(void)
{
    char buf[64];
    return my_snprintf(buf, sizeof buf, "%zu %llx",
                       sizeof buf, 0ULL);
}


-- 
           Summary: bogus warnings on x86_64-mingw32 due to
                    attribute((format(printf))) breakage
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mikpe at it dot uu dot se
GCC target triplet: x86_64-pc-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37768


             reply	other threads:[~2008-10-08  9:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-08  9:31 mikpe at it dot uu dot se [this message]
2008-10-08 16:16 ` [Bug c/37768] " joseph at codesourcery dot com
2008-10-09  7:05 ` mikpe at it dot uu dot se

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-37768-7665@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).