public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Steve Ellcey <sellcey@caviumnetworks.com>
To: <libc-alpha@sourceware.org>
Subject: Re: [PATCH]  Fix  warning from latest GCC in tst-printf.c
Date: Tue, 01 Nov 2016 17:21:00 -0000	[thread overview]
Message-ID: <1478020891.2891.45.camel@caviumnetworks.com> (raw)
In-Reply-To: <1477003405.8523.21.camel@caviumnetworks.com>

Ping.  One of the snprintf statements in this test is using a %.999999u
format so it is obvious that the test wants to test formats that would
go beyond the limit of the snprintf buffer and so we should ignore the
warnings in this test.

Steve Ellcey
sellcey@caviumnetworks.com



On Thu, 2016-10-20 at 15:43 -0700, Steve Ellcey wrote:
> GCC 7.0 (prerelease) adds a a new warning, -Wformat-length, if it
> thinks an snprintf call may go beyond the end of the buffer length
> being written to.  This warning is an approximation since GCC may not
> know how many characters a '%d' format will expand to, but it makes a
> worse case guess and warns if that would take the print beyond the
> buffer length.
> 
> Here is a fix for one GLIBC test that fails to compile due to this
> warning.  I think we want to ignore the warning in this case and not
> increase the buffer size because I believe the test is intentionally
> trying to go beyond the buffer limit.
> 
> The warnings are coming from the snprintf statements at line 225 and
> 228 of the original stdio-common/tst-printf.c and I could do a push
> and
> pop of the warning down at those lines but I thought it made more
> sense
> to put it up with the other DIAG_IGNORE.
> 
> OK to checkin?
> 
> Steve Ellcey
> sellcey@caviumnetworks.com
> 
> 
> 2016-10-20  Steve Ellcey  <sellcey@caviumnetworks.com>
> 
> 	* stdio-common/tst-printf.c: Ignore -Wformat-length warning.
> 
> 
> diff --git a/stdio-common/tst-printf.c b/stdio-common/tst-printf.c
> index 2896b18..1ae1eea 100644
> --- a/stdio-common/tst-printf.c
> +++ b/stdio-common/tst-printf.c
> @@ -32,6 +32,9 @@
>     The compiler warnings are not useful here.  */
>  DIAG_IGNORE_NEEDS_COMMENT (4.9, "-Wformat");
>  
> +/* Compiler warnings about format lengths should also be
> ignored.  */
> +DIAG_IGNORE_NEEDS_COMMENT (7.0, "-Wformat-length");
> +
>  static void rfg1 (void);
>  static void rfg2 (void);
>  static void rfg3 (void);

  reply	other threads:[~2016-11-01 17:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-20 22:43 Steve Ellcey
2016-11-01 17:21 ` Steve Ellcey [this message]
2016-11-01 17:37   ` Joseph Myers
2016-11-01 22:29     ` Steve Ellcey
2016-11-01 22:54       ` Joseph Myers

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=1478020891.2891.45.camel@caviumnetworks.com \
    --to=sellcey@caviumnetworks.com \
    --cc=libc-alpha@sourceware.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).