git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v4] Refactor recv_sideband()

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 28, 2016, 17:24 UTC
Message-ID
<xmqq60st9qg5.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<xmqqa8i59rph.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 28 quoted lines
> With input from Dscho that recent Git-for-Windows does the right
> thing without limiting us to use only a subset of stdio, perhaps we
> would want to squash something like this in.
>
> diff --git a/sideband.c b/sideband.c
> index 226a8c2..72e2c5c 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -58,13 +58,12 @@ int recv_sideband(const char *me, int in_stream, int out)
>  			 * Append a suffix to each nonempty line to clear the
>  			 * end of the screen line.
>  			 *
> -			 * The output is accumulated in a buffer and each line
> -			 * is printed to stderr using fprintf() with a single
> -			 * conversion specifier. This is a "best effort"
> -			 * approach to supporting both inter-process atomicity
> -			 * (single conversion specifiers are likely to end up
> -			 * in single atomic write() system calls) and the ANSI
> -			 * control code emulation under Windows.
> +			 * The output is accumulated in a buffer and
> +			 * each line is printed to stderr using
> +			 * fwrite(3).  This is a "best effort"
> +			 * approach to suppor inter-process atomicity
> +			 * (single fwrite(3) call is likely to end up
> +			 * in single atomic write() system calls).
>  			 */
>  			while ((brk = strpbrk(b, "\n\r"))) {
>  				int linelen = brk - b;

That may be good, but the remainder is crap. Sorry about the typo; s/output/outbuf/g is needed at least.

Show 19 quoted lines
> @@ -75,8 +74,7 @@ int recv_sideband(const char *me, int in_stream, int out)
>  				} else {
>  					strbuf_addf(&outbuf, "%c", *brk);
>  				}
> -				fprintf(stderr, "%.*s", (int)outbuf.len,
> -					outbuf.buf);
> +				fwrite(output.buf, 1, output.len, stderr);
>  				strbuf_reset(&outbuf);
>  				strbuf_addf(&outbuf, "%s", PREFIX);
>  
> @@ -98,7 +96,7 @@ int recv_sideband(const char *me, int in_stream, int out)
>  	}
>  
>  	if (outbuf.len > 0)
> -		fprintf(stderr, "%.*s", (int)outbuf.len, outbuf.buf);
> +		fwrite(output.buf, 1, output.len, stderr);
>  	strbuf_release(&outbuf);
>  	return retval;
>  }

But we would be better off using the real write(2), now Windows port does not limit us to stdio.

And then that made me stare at the patch even more. We still write some error messages to stderr in the updated code (without my crap SQUASH) inside "while (!retval)" loop:

	while (retval == 0) {
		int band, len;
		len = packet_read(in_stream, NULL, NULL, buf, LARGE_PACKET_MAX, 0);
		if (len == 0)
			break;
		if (len < 1) {
			fprintf(stderr, "%s: protocol error: no band designator\n", me);
			retval = SIDEBAND_PROTOCOL_ERROR;
			break;
		}
		band = buf[0] & 0xff;
		buf[len] = '\0';
		len--;
		switch (band) {
		case 3:
			fprintf(stderr, "%s%s\n", PREFIX, buf + 1);
			retval = SIDEBAND_REMOTE_ERROR;
			break;
		case 2:
			...
			while ((brk = strpbrk(b, "\n\r"))) {
				...
				write(2, outbuf.buf, outbuf.len);
				...
			}
			if (*b)
				strbuf_addf(&outbuf, "%s", b);
			break;
		case 1:
			write_or_die(out, buf + 1, len);
			break;
		default:
			fprintf(stderr, "%s: protocol error: bad band #%d\n",
				me, band);
			retval = SIDEBAND_PROTOCOL_ERROR;
			break;
		}
	}
	if (outbuf.len > 0)
		write(2, outbuf.buf, outbuf.len);

In general, mixing stdio and raw file descriptor access is not such a good idea, but these remaining calls to fprintf(stderr, ...) above are for error-exit codepath, so from that point of view, the above illustration may be acceptable, but there is still one niggle.

When we exit the loop because we set retval to a non-zero value, should we still drain the outbuf?

IOW, shouldn't the if statement after "while (!retval)" loop be more like this?

	if (!retval && outbuf.len)
        	write(2, outbuf.buf, outbuf,len);
Thanks.
Previous: Junio C HamanoNext: Nicolas Pitre
Message 35 of 60 in “Refactor recv_sideband()”
  1. Refactor recv_sideband()Lukas Fleischer, Jun 13, 2016
  2. Nicolas PitreJun 13, 2016
  3. Johannes SchindelinJun 14, 2016
  4. Nicolas PitreJun 14, 2016
  5. Johannes SchindelinJun 14, 2016
  6. Nicolas PitreJun 14, 2016
  7. Refactor recv_sideband()Lukas Fleischer, Jun 14, 2016
  8. Lukas FleischerJun 14, 2016
  9. Junio C HamanoJun 14, 2016
  10. Jeff KingJun 15, 2016
  11. Jeff KingJun 24, 2016
  12. Johannes SchindelinJun 24, 2016
  13. Jeff KingJun 24, 2016
  14. Junio C HamanoJun 24, 2016
  15. Lukas FleischerJun 27, 2016
  16. Junio C HamanoJun 27, 2016
  17. Jeff KingJun 27, 2016
  18. Junio C HamanoJun 27, 2016
  19. Lukas FleischerJun 27, 2016
  20. Nicolas PitreJun 27, 2016
  21. Lukas FleischerJun 28, 2016
  22. Junio C HamanoJun 28, 2016
  23. Johannes SchindelinJun 28, 2016
  24. Johannes SchindelinJun 28, 2016
  25. Junio C HamanoJun 28, 2016
  26. Johannes SchindelinJun 28, 2016
  27. Dennis KaarsemakerJun 24, 2016
  28. Refactor recv_sideband()Lukas Fleischer, Jun 22, 2016
  29. Nicolas PitreJun 22, 2016
  30. Nicolas PitreJun 22, 2016
  31. Lukas FleischerJun 23, 2016
  32. Nicolas PitreJun 23, 2016
  33. Refactor recv_sideband()Lukas Fleischer, Jun 28, 2016
  34. Junio C HamanoJun 28, 2016
  35. Junio C HamanoJun 28, 2016
  36. Nicolas PitreJun 28, 2016
  37. Junio C HamanoJun 28, 2016
  38. Nicolas PitreJun 28, 2016
  39. Junio C HamanoJun 28, 2016
  40. Nicolas PitreJun 28, 2016
  41. Junio C HamanoJun 28, 2016
  42. Nicolas PitreJun 28, 2016
  43. Junio C HamanoJun 28, 2016
  44. Junio C HamanoJun 28, 2016
  45. Junio C HamanoJun 29, 2016
  46. Nicolas PitreJun 29, 2016
  47. Nicolas PitreJun 29, 2016
  48. Junio C HamanoJun 29, 2016
  49. Lukas FleischerJun 30, 2016
  50. Junio C HamanoJul 1, 2016
  51. Nicolas PitreJul 5, 2016
  52. Junio C HamanoJul 6, 2016
  53. Nicolas PitreJul 7, 2016
  54. Nicolas PitreJun 14, 2016
  55. Nicolas PitreJun 14, 2016
  56. Junio C HamanoJun 14, 2016
  57. Lukas FleischerJun 14, 2016
  58. Junio C HamanoJun 14, 2016
  59. Nicolas PitreJun 14, 2016
  60. Lukas FleischerJun 19, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.