From: Jonathan Nieder <jrnieder@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Thomas Gummerer <t.gummerer@gmail.com>, Jeff King <peff@peff.net>,
git@vger.kernel.org, Josh Steadmon <steadmon@google.com>,
Masaya Suzuki <masayasuzuki@google.com>
Subject: Re: [PATCH] config.mak.dev: add -Wformat
Date: Thu, 3 Jan 2019 10:54:27 -0800 [thread overview]
Message-ID: <20190103185427.GA237830@google.com> (raw)
In-Reply-To: <xmqqa7khisue.fsf@gitster-ct.c.googlers.com>
Hi,
Junio C Hamano wrote:
> I think it is a good idea to give fallback/redundancy for this
> case. I do not have strong opinion between -Wall and -Wformat,
> but I'd probably vote for the former if pressed.
>
> -- >8 --
> From: Thomas Gummerer <t.gummerer@gmail.com>
> Date: Fri, 12 Oct 2018 19:40:37 +0100
> Subject: [PATCH] config.mak.dev: add -Wformat
>
> 801fa63a90 ("config.mak.dev: add -Wformat-security", 2018-09-08)
> added the "-Wformat-security" to the flags set in config.mak.dev.
> In the gcc man page this is documented as:
>
> If -Wformat is specified, also warn about uses of format
> functions that represent possible security problems. [...]
>
> The commit did however not add the "-Wformat" flag, but instead
> relied on the fact that "-Wall" is set in the Makefile by default
> and that "-Wformat" is part of "-Wall".
>
> Unfortunately, those who use config.mak.autogen generated with the
> autoconf to configure toolchain do *not* get "-Wall" in their CFLAGS
> and the added -Wformat-security had no effect. Worse yet, newer
> versions of gcc (gcc 8.2.1 in this particular case) warn about the
> lack of "-Wformat" and thus compilation fails only with this option
> set.
>
> We could fix it by adding "-Wformat", but in general we do want all
> checks included in "-Wall", so let's add it to config.mak.dev to
> cover more cases.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> Helped-by: Jeff King <peff@peff.net>
> Helped-by: Jonathan Nieder <jrnieder@gmail.com>
> [jc: s/-Wformat/-Wall/]
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> config.mak.dev | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks for tying up this loose end.
next prev parent reply other threads:[~2019-01-03 18:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-12 18:40 [PATCH] config.mak.dev: add -Wformat Thomas Gummerer
2018-10-12 18:45 ` Jeff King
2018-10-12 18:54 ` Jonathan Nieder
2018-10-12 19:11 ` Jeff King
2018-10-12 19:15 ` Thomas Gummerer
2018-12-27 18:59 ` Jonathan Nieder
2019-01-03 16:55 ` Junio C Hamano
2019-01-03 18:54 ` Jonathan Nieder [this message]
2019-01-06 18:17 ` Thomas Gummerer
2019-01-07 17:04 ` Junio C Hamano
2019-01-07 21:16 ` Jonathan Nieder
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=20190103185427.GA237830@google.com \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=masayasuzuki@google.com \
--cc=peff@peff.net \
--cc=steadmon@google.com \
--cc=t.gummerer@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.