git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Ramsay Jones <ramsay@ramsayjones.plus.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	GIT Mailing-list <git@vger.kernel.org>
Subject: Re: [PATCH] difftool.c: mark a file-local symbol with static
Date: Thu, 1 Dec 2016 13:50:57 -0500	[thread overview]
Message-ID: <20161201185056.eso5rhec7izlbywa@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqq60n3bjel.fsf@gitster.mtv.corp.google.com>

On Thu, Dec 01, 2016 at 10:20:50AM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > I don't have a preference on which direction we go, but yes, right now
> > we are in an awkward middle ground. We should do one of:
> >
> >   1. Drop -Wno-format-zero-length from DEVELOPER_CFLAGS and make sure
> >      future patches to do not violate it.
> >
> >   2. Declare warning("") as OK.
> >
> > I still think the warning is silly, but (1) has value in that it
> > produces the least surprise and annoyance to various people building
> > Git.
> 
> What is most awkward is that "make", with no customization out of
> box, suggests to use -Wall in CFLAGS and triggers the misguided
> warning, and DEVELOPER_CFLAGS, partly because it adds -Werror to
> turn warnings (including this misguided one) into errors, disables
> it with -Wno-format-zero-length.  As a result:
> 
>  - Casual builders that follow our suggestion get warnings.
> 
>  - Developers do not notice their new code may make the "casual
>    builder" experience worse.
> 
> That is totally backwards.  That is probably what you meant by "the
> least surprise and annoyance"?

Yes, exactly. :)

The surprise and annoyance for (1) is that people who get caught up by
the warning while writing new patches say "this warning is stupid, why
don't we disable it". But that is a much smaller number of people to be
annoyed.

> I also still think that any_printf_like_function("%s", "") looks
> silly.  I know that we've already started moving in that direction
> and we stopped at a place we do not want to be in, but perhaps it
> was a mistake to move in that direction in the first place.  I am
> tempted to say we should do something like the attached, but that
> may not fly well, as I suspect that -Wno-format-zero-length may be a
> lot more exotic than the -Wall compiler option.

Yeah, I think portability concerns are what caused us not to go down
that road in the first place. But I think it's also a mistake to put too
much into CFLAGS, because somebody who wants to override one flag has to
repeat the rest. So, e.g., right now I might do:

  make CFLAGS="-O3 -Wall"

to bump the optimization level. But if our codebase relies on
-Wno-format-zero-length being there, then I have to know to put it in
there, too.

You can work around that with an extra make variable, but that also
makes it harder to disable if your compiler doesn't like it.

> An obvious second
> best option would be to drop -Wall from the "everybody" CFLAGS and
> move it to DEVELOPER_CFLAGS instead.

Yeah, though that doesn't help the example above.

As ugly as warning("%s", "") is, I think it may be the thing that annoys
the smallest number of people.

-Peff

  reply	other threads:[~2016-12-01 18:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-29 17:36 [PATCH] difftool.c: mark a file-local symbol with static Ramsay Jones
2016-11-30 11:07 ` Johannes Schindelin
2016-11-30 19:57   ` Ramsay Jones
2016-11-30 20:40     ` Junio C Hamano
2016-11-30 21:25       ` Jeff King
2016-11-30 22:37         ` Ramsay Jones
2016-11-30 23:18           ` Jeff King
2016-11-30 23:46             ` Junio C Hamano
2016-12-01  1:18               ` Ramsay Jones
2016-12-01  4:02                 ` Jeff King
2016-12-01 18:20                   ` Junio C Hamano
2016-12-01 18:50                     ` Jeff King [this message]
2017-01-22  5:26                       ` David Aguilar
2017-01-24 14:23                         ` Jeff King
2017-01-24 21:52                           ` Junio C Hamano
2017-01-24 23:05                             ` Jeff King
2017-01-25 10:36                               ` Fixing the warning about warning(""); was: " Johannes Schindelin
2017-01-25 18:35                                 ` Jeff King
2017-01-25 21:28                                   ` Junio C Hamano
2017-01-25 22:01                                     ` Jeff King
2017-01-26  6:39                                       ` Johannes Sixt
2017-01-26 11:37                                         ` Johannes Schindelin
2017-01-26 14:35                                           ` Jeff King
2017-01-26 14:32                                         ` Jeff King
2017-01-26 18:26                                           ` Junio C Hamano
2017-01-26 11:16                                   ` Johannes Schindelin
2017-01-26 14:39                                     ` Jeff King
2017-01-26 14:49                                       ` Johannes Schindelin

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20161201185056.eso5rhec7izlbywa@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ramsay@ramsayjones.plus.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).