Re: [PATCH] sequencer: cleanup for gcc 8.2.1 warning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> I'd have to say that the ability to create an empty file is more
> important in the longer term.  Can't the workaround be done to
> write_file() instead?  I actually do not mind if the solution were
> to introduce a newhelper "write_empty_file()", but the way it is
> written in the code before this patch, i.e.
>
> 	write_file(FILENAME, "")
>
> is so obvious a way to create an empty file, so if we do not have to
> resort to such a hackery to special case an empty file, that would
> be preferrable.

It turns out that we have dealt with this before.

The trick employed by 7d7d6802 ("silence a bunch of
format-zero-length warnings", 2014-05-04) is still a caller side
workaround, but to do

	-	status_printf_ln(s, GIT_COLOR_NORMAL, "");
	+	status_printf_ln(s, GIT_COLOR_NORMAL, "%s", "");

to the function whose third parameter is printf format.

I do not know if it is a good idea to define a macro

	#define	EMPTY_CONTENTS	"%s", ""

in git-compat-util.h and then replace all the occurrences of "%s", ""
in the source code with it.  That way, we'd be able to create an
empty file with

	write_file(FILENAME, EMPTY_CONTENTS);

and write out an empty line with

	status_printf_ln(s, GIT_COLOR_NORMAL, EMPTY_CONTENTS);

and they would read naturally.  But may be it is a bit too cute an
idea?  I dunno.


	



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux