[PATCH] rev-list: handle %x00 NUL in user format

[PATCH] rev-list: handle %x00 NUL in user format

[Jeff King]

The code paths for showing commits in "git log" and "git
rev-list --graph" correctly handle embedded NULs by looking
only at the resulting strbuf's length, and never treating it
as a C string. The code path for regular rev-list, however,
used printf("%s"), which resulted in truncated output. This
patch uses fwrite instead, like the --graph code path.

Signed-off-by: Jeff King <peff@peff.net>
---
I built this on master, though it is perhaps maint-worthy. The buggy
line seems to blame back to at least v1.5.3-era.

Erik mentioned a potential problem with fwrite() and the way we handle
ANSI emulation for Windows. I think if there is a problem, then the same
problem exists in the --graph code, and we should do this, and then fix
both on top.

 builtin/rev-list.c         |    6 ++++--
 t/t6006-rev-list-format.sh |    8 ++++++++
 t/test-lib.sh              |    4 ++++
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index efe9360..3b2dca0 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)
 			}
 		} else {
 			if (revs->commit_format != CMIT_FMT_USERFORMAT ||
-			    buf.len)
-				printf("%s%c", buf.buf, info->hdr_termination);
+			    buf.len) {
+				fwrite(buf.buf, 1, buf.len, stdout);
+				putchar(info->hdr_termination);
+			}
 		}
 		strbuf_release(&buf);
 	} else {
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index cccacd4..d918cc0 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -162,6 +162,14 @@ commit 131a310eb913d107dd3c09a65d1651175898735d
 commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
 EOF
 
+test_expect_success '%x00 shows NUL' '
+	echo  >expect commit f58db70b055c5718631e5c61528b28b12090cdea &&
+	echo >>expect fooQbar &&
+	git rev-list -1 --format=foo%x00bar HEAD >actual.nul &&
+	nul_to_q <actual.nul >actual &&
+	test_cmp expect actual
+'
+
 test_expect_success '%ad respects --date=' '
 	echo 2005-04-07 >expect.ad-short &&
 	git log -1 --date=short --pretty=tformat:%ad >output.ad-short master &&
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 2af8f10..bbe79e0 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -248,6 +248,10 @@ test_decode_color () {
 		-e 's/.\[m/<RESET>/g'
 }
 
+nul_to_q () {
+	perl -pe 'y/\000/Q/'
+}
+
 q_to_nul () {
 	perl -pe 'y/Q/\000/'
 }
-- 
1.7.3.1.203.g81d8.dirty

Re: [PATCH] rev-list: handle %x00 NUL in user format

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Erik mentioned a potential problem with fwrite() and the way we handle
> ANSI emulation for Windows. I think if there is a problem, then the same
> problem exists in the --graph code, and we should do this, and then fix
> both on top.

I am quite sure that --graph codepath is used a lot less often than this
codepath, and most users do not hit the problem you are fixing---that is
why it took so long to get noticed.  I think this printf() has been there
from the beginning, even though the possibility of placing a NUL in
buf.buf may have come much later, like when %x00 was introduced).

Use of fwrite() here will affect all Windows users who use color (probably
most of them), no?  It may be a deliberate regression, but it has a real
cost associated with it; it will break more usual uses on Windows to help
an obscure use case on POSIX.

As to emulating fwrite(3) on Windows, even though there are a lot of
callers of fwrite(3) that do not want the payload colored, it is probably
sufficient to check isatty(fileno(stream)) upfront like all the other
winansi_fEMULATED() functions do, and to make ansi_emulate() call the
system fwrite(3) directly.

I'll queue this patch on a side branch and I may even feel like merging it
to 'next', but we would need to hear from Windows folks how they want to
proceed soon.

Re: [PATCH] rev-list: handle %x00 NUL in user format

[Jeff King]

On Wed, Oct 13, 2010 at 02:58:40PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > Erik mentioned a potential problem with fwrite() and the way we handle
> > ANSI emulation for Windows. I think if there is a problem, then the same
> > problem exists in the --graph code, and we should do this, and then fix
> > both on top.
> 
> I am quite sure that --graph codepath is used a lot less often than this
> codepath, and most users do not hit the problem you are fixing---that is
> why it took so long to get noticed.  I think this printf() has been there
> from the beginning, even though the possibility of placing a NUL in
> buf.buf may have come much later, like when %x00 was introduced).
> 
> Use of fwrite() here will affect all Windows users who use color (probably
> most of them), no?  It may be a deliberate regression, but it has a real
> cost associated with it; it will break more usual uses on Windows to help
> an obscure use case on POSIX.

Yeah, I don't want to regress Windows users in an actual release. I was
hoping for you to queue it on a side branch, and then have Windows
people apply the proper fix on top before getting it merged in.

-Peff