Re: [RFC PATCH] vreportf: ensure sensible ordering of normal and error output

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 30, 2021, 05:13 UTC
Message-ID: <xmqqtufu2pll.fsf@gitster.g>
In-Reply-To: <20211130043946.19987-1-sunshine@sunshineco.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 5 quoted lines

> This is RFC because I naturally worry about potential fallout from
> making a change to such a core function. I can't think of any case that
> it wouldn't be advantageous to flush stdout before stderr, so this
> change _seems_ safe, however, it may be that I'm just not imaginative
> enough, hence my hesitancy.

If stdout and stderr are both going to the same place (e.g. the user's terminal), this would probably is an improvement, but if the standard output is going to a pipe talking to another process, which may care when the output is flushed, this may hurt.

But as long as the calling code is using stdio, it cannot precisely control when the buffered contents are flushed anyway, so as long as the caller has working standard output, this may be OK.

Hits from "git grep -l vreportf" includes http-backend.c; where is its standard output connected, and can it have some unflushed stuff in its standard output buffer, I wonder?

Show 15 quoted lines

>  usage.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/usage.c b/usage.c
> index c7d233b0de..0fc7640b25 100644
> --- a/usage.c
> +++ b/usage.c
> @@ -27,6 +27,7 @@ void vreportf(const char *prefix, const char *err, va_list params)
>  	}
>  
>  	*(p++) = '\n'; /* we no longer need a NUL */
> +	fflush(stdout);
>  	fflush(stderr);
>  	write_in_full(2, msg, p - msg);
>  }