On 30/11/16 21:25, Jeff King wrote:
> On Wed, Nov 30, 2016 at 12:40:25PM -0800, Junio C Hamano wrote:
>
>> Ramsay Jones <ram...@ramsayjones.plus.com> writes:
>>
>>> [I have fixed my config.mak file now, so I don't see the warning
>>> anymore! Having -Wno-format-zero-length in DEVELOPER_CFLAGS, or
>>> not, is a separate matter.]
>>
>> I suspect that 658df95a4a ("add DEVELOPER makefile knob to check for
>> acknowledged warnings", 2016-02-25) took it from me (namely, Make
>> script in my 'todo' branch). In turn, I added it to my set of flags
>> in order to squelch this exact warning, so...
>
> For anybody interested in the history, we started using this when
> status_printf() got the format attribute. Relevant patch and discussion:
>
>
> http://public-inbox.org/git/20130710002328.gc19...@sigill.intra.peff.net/T/#u
Ah, thank you! I've been trying to remember this for the last hour or so ...
(I misremembered something about gettext, and went looking in the wrong
direction ;-) ).
> We went with disabling the warning because it really is wrong. It makes
> an assumption that calling a format function with an empty string
> doesn't do anything, but that's only true of the stock printf functions.
> Our custom functions _do_ have a side effect in this case.
Yes, I agree, gcc is making an unwarranted assumption.
> The other options are to have a special function for "print a warning
> (or status) line with no content". Or to teach those functions to handle
> newlines specially. We've often discussed that you should be able to do:
>
> warning("foo\nbar");
>
> and have it print:
>
> warning: foo
> warning: bar
>
> That's useful in itself, and would probably make cases like this easier
> to handle, too. But it's a pretty big change. Another option would be to
> just teach formatting functions to handle a single "\n" as a synonym for
> the empty string (or even detect trailing newlines and avoid appending
> our own in that case). That would mean you could do:
>
> warning("\n");
>
> to print a blank line. That's arguably more obvious about the intent to
> a reader (I say arguably because the new behavior _is_ subtle if you
> happen to know that warning() usually appends a newline).
Yes, I remember the discussion now and agree that this could
cause problems.
> Anyway. Those are all options, but I don't think there is any problem
> with sticking with warning("") for now. It is not the first part of the
> code that tickles the format-zero-length warning.
Hmm, well I have been building git for some time with the warning
enabled without problem.
[I can see a few examples of 'status_printf_ln(s, c, "%s", "");' in
git-grep output, so ...]
I am not suggesting any change here, and was just curious why it
seemed to be unnecessary now (I knew it was necessary at one time).
ATB,
Ramsay Jones
