* git log doesn't allow %x00 in custom format anymore? @ 2010-10-07 11:25 Kirill Likhodedov 2010-10-07 14:10 ` Jeff King 0 siblings, 1 reply; 19+ messages in thread From: Kirill Likhodedov @ 2010-10-07 11:25 UTC (permalink / raw) To: git Hello, I've noticed that at least since Git 1.7.2.3 custom pretty format behaves strangely if there is a null-byte in the format: Without null byte: > git log --pretty=format:%H-%ct Outputs something like: ee5d714b95d133ff555bc8c7933dc752b5b277f5-1285954314 cb1b9dd688d9cf155257c94e749172820b56d87a-1285954240 b4c75be10b14d021003853e527e47ad88dc5a55b-1285833610 1963187da6a45f898e62e4e922faac6b9382b4e4-1285807494 With a null byte > git log --pretty=format:%H%x00%ct Ignores anything appearing after the null byte: ee5d714b95d133ff555bc8c7933dc752b5b277f5 cb1b9dd688d9cf155257c94e749172820b56d87a b4c75be10b14d021003853e527e47ad88dc5a55b 1963187da6a45f898e62e4e922faac6b9382b4e4 Other bytes behave fine. Using %x00 worked in Git 1.7.1 and stopped working in 1.7.2.3 (or even earlier). Is it a bug or a feature (not allowing null bytes in the custom format anymore)? If it is a feature, the documentation should have note about it. Now it's even proposing to use %x00: %x00: print a byte from a hex code Thanks a lot. ---------------------------------- Kirill Likhodedov JetBrains, Inc http://www.jetbrains.com "Develop with pleasure!" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 11:25 git log doesn't allow %x00 in custom format anymore? Kirill Likhodedov @ 2010-10-07 14:10 ` Jeff King 2010-10-07 14:35 ` Kirill Likhodedov 0 siblings, 1 reply; 19+ messages in thread From: Jeff King @ 2010-10-07 14:10 UTC (permalink / raw) To: Kirill Likhodedov; +Cc: git On Thu, Oct 07, 2010 at 03:25:29PM +0400, Kirill Likhodedov wrote: > With a null byte > > git log --pretty=format:%H%x00%ct > Ignores anything appearing after the null byte: > > ee5d714b95d133ff555bc8c7933dc752b5b277f5 > cb1b9dd688d9cf155257c94e749172820b56d87a > b4c75be10b14d021003853e527e47ad88dc5a55b > 1963187da6a45f898e62e4e922faac6b9382b4e4 > > Other bytes behave fine. > > Using %x00 worked in Git 1.7.1 and stopped working in 1.7.2.3 (or even earlier). I can't reproduce using v1.7.2.3. Are you sure your pager or terminal isn't hiding everything after the NUL? Have you tried piping it through "xxd" or "cat -A"? I get: $ git log -1 --pretty=foo%x00bar | xxd 0000000: 666f 6f00 6261 720a foo.bar. $ git log -1 --pretty=foo%x00bar | cat -A foo^@bar$ > Is it a bug or a feature (not allowing null bytes in the custom format anymore)? If it is not working, it is most definitely a bug. -Peff ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 14:10 ` Jeff King @ 2010-10-07 14:35 ` Kirill Likhodedov 2010-10-07 14:46 ` Jeff King 2010-10-07 15:07 ` Johannes Sixt 0 siblings, 2 replies; 19+ messages in thread From: Kirill Likhodedov @ 2010-10-07 14:35 UTC (permalink / raw) To: Jeff King; +Cc: git My bad, this happens only on Windows (at least not on Mac OS X). So it more likely is an msys porting problem or something like that, not a bug of Git itself. I've tested it on Windows XP SP3 with official installer for Git 1.7.2.3 and 1.7.3.1 I don't think it's a terminal problem. I've tried saving the output in a file: git log --pretty=format:%H%x00%ct >a.txt I've also tried invoking the git process from a program and catching its output. How could I report this bug? Or this message is enough? :) 07.10.2010, в 18:10, Jeff King написал(а): > On Thu, Oct 07, 2010 at 03:25:29PM +0400, Kirill Likhodedov wrote: > >> With a null byte >>> git log --pretty=format:%H%x00%ct >> Ignores anything appearing after the null byte: >> >> ee5d714b95d133ff555bc8c7933dc752b5b277f5 >> cb1b9dd688d9cf155257c94e749172820b56d87a >> b4c75be10b14d021003853e527e47ad88dc5a55b >> 1963187da6a45f898e62e4e922faac6b9382b4e4 >> >> Other bytes behave fine. >> >> Using %x00 worked in Git 1.7.1 and stopped working in 1.7.2.3 (or even earlier). > > I can't reproduce using v1.7.2.3. Are you sure your pager or terminal > isn't hiding everything after the NUL? Have you tried piping it through > "xxd" or "cat -A"? I get: > > $ git log -1 --pretty=foo%x00bar | xxd > 0000000: 666f 6f00 6261 720a foo.bar. > > $ git log -1 --pretty=foo%x00bar | cat -A > foo^@bar$ > >> Is it a bug or a feature (not allowing null bytes in the custom format anymore)? > > If it is not working, it is most definitely a bug. > > -Peff ---------------------------------- Kirill Likhodedov JetBrains, Inc http://www.jetbrains.com "Develop with pleasure!" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 14:35 ` Kirill Likhodedov @ 2010-10-07 14:46 ` Jeff King 2010-10-07 15:07 ` Johannes Sixt 1 sibling, 0 replies; 19+ messages in thread From: Jeff King @ 2010-10-07 14:46 UTC (permalink / raw) To: Kirill Likhodedov; +Cc: git On Thu, Oct 07, 2010 at 06:35:07PM +0400, Kirill Likhodedov wrote: > My bad, this happens only on Windows (at least not on Mac OS X). > > So it more likely is an msys porting problem or something like that, not a bug of Git itself. > I've tested it on Windows XP SP3 with official installer for Git 1.7.2.3 and 1.7.3.1 > > I don't think it's a terminal problem. I've tried saving the output in a file: > git log --pretty=format:%H%x00%ct >a.txt > > I've also tried invoking the git process from a program and catching its output. > > How could I report this bug? Or this message is enough? :) It might get seen here, but there is also an msysgit list: msysgit@googlegroups.com -Peff ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 14:35 ` Kirill Likhodedov 2010-10-07 14:46 ` Jeff King @ 2010-10-07 15:07 ` Johannes Sixt 2010-10-07 15:18 ` Kirill Likhodedov 1 sibling, 1 reply; 19+ messages in thread From: Johannes Sixt @ 2010-10-07 15:07 UTC (permalink / raw) To: Kirill Likhodedov; +Cc: Jeff King, git Am 10/7/2010 16:35, schrieb Kirill Likhodedov: > My bad, this happens only on Windows (at least not on Mac OS X). With git rev-list, it also happens on Linux: $ git log -1 --pretty=foo%x00bar HEAD | od -c 0000000 f o o \0 b a r \n 0000010 $ git rev-list -1 --pretty=foo%x00bar HEAD | od -c 0000000 c o m m i t 8 7 f a f 1 0 9 0 0000020 5 d 1 f 8 a b 1 e 9 a c 2 4 c c 0000040 3 e f e d 8 1 f a 7 e 2 9 6 7 \n 0000060 f o o \n 0000064 $ git version git version 1.7.3.67.gcc234 -- Hannes ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 15:07 ` Johannes Sixt @ 2010-10-07 15:18 ` Kirill Likhodedov 2010-10-07 17:29 ` Jeff King 0 siblings, 1 reply; 19+ messages in thread From: Kirill Likhodedov @ 2010-10-07 15:18 UTC (permalink / raw) To: Johannes Sixt; +Cc: Jeff King, git > With git rev-list, it also happens on Linux: > > $ git log -1 --pretty=foo%x00bar HEAD | od -c > 0000000 f o o \0 b a r \n > 0000010 > $ git rev-list -1 --pretty=foo%x00bar HEAD | od -c > 0000000 c o m m i t 8 7 f a f 1 0 9 0 > 0000020 5 d 1 f 8 a b 1 e 9 a c 2 4 c c > 0000040 3 e f e d 8 1 f a 7 e 2 9 6 7 \n > 0000060 f o o \n > 0000064 > $ git version > git version 1.7.3.67.gcc234 > Hannes, Thanks for pointing that out. I confirm that on Mac OS X that happens for rev-list as well. # git log --pretty=format:foo%x00bar HEAD -1 | od -c 0000000 f o o \0 b a r 0000007 # git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c 0000000 c o m m i t 2 3 6 0 1 a 2 c 3 0000020 e 4 6 4 a 4 4 7 9 f 1 7 7 4 e 3 0000040 6 e a 5 b 9 5 8 b 4 6 0 5 2 1 \n 0000060 f o o \n 0000064 And it's not a new issue: # git version git version 1.7.1 So here's what we have now about this bug: 1. It happens since 1.7.1 for rev-list on all platforms (at least since 1.7.1 on Mac OS X and 1.7.3 on Linux). 2. It also happens at least since 1.7.2.3 for log on Windows. Sorry for giving some confusion in my previous messages. I probably tested 'rev-list' at the time when I've recovered the problem, but I reported it as a problem with 'log'. ---------------------------------- Kirill Likhodedov JetBrains, Inc http://www.jetbrains.com "Develop with pleasure!" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 15:18 ` Kirill Likhodedov @ 2010-10-07 17:29 ` Jeff King 2010-10-07 17:40 ` Matthieu Moy 2010-10-07 17:41 ` Erik Faye-Lund 0 siblings, 2 replies; 19+ messages in thread From: Jeff King @ 2010-10-07 17:29 UTC (permalink / raw) To: Kirill Likhodedov; +Cc: Johannes Sixt, git On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote: > Thanks for pointing that out. > I confirm that on Mac OS X that happens for rev-list as well. > > # git log --pretty=format:foo%x00bar HEAD -1 | od -c > 0000000 f o o \0 b a r > 0000007 > > # git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c > 0000000 c o m m i t 2 3 6 0 1 a 2 c 3 > 0000020 e 4 6 4 a 4 4 7 9 f 1 7 7 4 e 3 > 0000040 6 e a 5 b 9 5 8 b 4 6 0 5 2 1 \n > 0000060 f o o \n > 0000064 Ugh. Even worse, it does print with --graph, which uses a slightly different code path. $ git rev-list --graph -1 --format=foo%x00bar HEAD | cat -A * commit 81d866a6a213d5524ce389369377ba3529461e1b$ |\ foo^@bar$ I am inclined to call the rev-list behavior a bug, and the fix is probably: 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 { ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 17:29 ` Jeff King @ 2010-10-07 17:40 ` Matthieu Moy 2010-10-07 18:02 ` Drew Northup 2010-10-07 17:41 ` Erik Faye-Lund 1 sibling, 1 reply; 19+ messages in thread From: Matthieu Moy @ 2010-10-07 17:40 UTC (permalink / raw) To: Jeff King; +Cc: Kirill Likhodedov, Johannes Sixt, git Jeff King <peff@peff.net> writes: > 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 { Sounds like a sane thing to do, yes. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 17:40 ` Matthieu Moy @ 2010-10-07 18:02 ` Drew Northup 0 siblings, 0 replies; 19+ messages in thread From: Drew Northup @ 2010-10-07 18:02 UTC (permalink / raw) To: Matthieu Moy; +Cc: Jeff King, Kirill Likhodedov, Johannes Sixt, git On Thu, 2010-10-07 at 19:40 +0200, Matthieu Moy wrote: > Jeff King <peff@peff.net> writes: > > > 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 { > > Sounds like a sane thing to do, yes. Agreed. I could have sworn that printf() used standard C-strings which terminate with %x00! -- -Drew Northup ________________________________________________ "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 17:29 ` Jeff King 2010-10-07 17:40 ` Matthieu Moy @ 2010-10-07 17:41 ` Erik Faye-Lund 2010-10-07 17:43 ` Erik Faye-Lund ` (2 more replies) 1 sibling, 3 replies; 19+ messages in thread From: Erik Faye-Lund @ 2010-10-07 17:41 UTC (permalink / raw) To: Jeff King; +Cc: Kirill Likhodedov, Johannes Sixt, git On Thu, Oct 7, 2010 at 7:29 PM, Jeff King <peff@peff.net> wrote: > On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote: > >> Thanks for pointing that out. >> I confirm that on Mac OS X that happens for rev-list as well. >> >> # git log --pretty=format:foo%x00bar HEAD -1 | od -c >> 0000000 f o o \0 b a r >> 0000007 >> >> # git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c >> 0000000 c o m m i t 2 3 6 0 1 a 2 c 3 >> 0000020 e 4 6 4 a 4 4 7 9 f 1 7 7 4 e 3 >> 0000040 6 e a 5 b 9 5 8 b 4 6 0 5 2 1 \n >> 0000060 f o o \n >> 0000064 > > Ugh. Even worse, it does print with --graph, which uses a slightly > different code path. > > $ git rev-list --graph -1 --format=foo%x00bar HEAD | cat -A > * commit 81d866a6a213d5524ce389369377ba3529461e1b$ > |\ foo^@bar$ > > I am inclined to call the rev-list behavior a bug, and the fix is > probably: > > 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 { This gives me a bit of a deja-vu: 1fb5fdd Also, fwriting like that to stdout might be a bit troublesome on Windows because the string won't end up going through our ANSI-emulation. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 17:41 ` Erik Faye-Lund @ 2010-10-07 17:43 ` Erik Faye-Lund 2010-10-07 17:50 ` Jeff King 2010-10-07 17:52 ` Matthieu Moy 2 siblings, 0 replies; 19+ messages in thread From: Erik Faye-Lund @ 2010-10-07 17:43 UTC (permalink / raw) To: Jeff King; +Cc: Kirill Likhodedov, Johannes Sixt, git On Thu, Oct 7, 2010 at 7:41 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote: > On Thu, Oct 7, 2010 at 7:29 PM, Jeff King <peff@peff.net> wrote: >> On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote: >> >>> Thanks for pointing that out. >>> I confirm that on Mac OS X that happens for rev-list as well. >>> >>> # git log --pretty=format:foo%x00bar HEAD -1 | od -c >>> 0000000 f o o \0 b a r >>> 0000007 >>> >>> # git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c >>> 0000000 c o m m i t 2 3 6 0 1 a 2 c 3 >>> 0000020 e 4 6 4 a 4 4 7 9 f 1 7 7 4 e 3 >>> 0000040 6 e a 5 b 9 5 8 b 4 6 0 5 2 1 \n >>> 0000060 f o o \n >>> 0000064 >> >> Ugh. Even worse, it does print with --graph, which uses a slightly >> different code path. >> >> $ git rev-list --graph -1 --format=foo%x00bar HEAD | cat -A >> * commit 81d866a6a213d5524ce389369377ba3529461e1b$ >> |\ foo^@bar$ >> >> I am inclined to call the rev-list behavior a bug, and the fix is >> probably: >> >> 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 { > > This gives me a bit of a deja-vu: 1fb5fdd > Never mind that, I'm a bit too tired and got struck with a bit of paranoia :P ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 17:41 ` Erik Faye-Lund 2010-10-07 17:43 ` Erik Faye-Lund @ 2010-10-07 17:50 ` Jeff King 2010-10-07 17:52 ` Matthieu Moy 2 siblings, 0 replies; 19+ messages in thread From: Jeff King @ 2010-10-07 17:50 UTC (permalink / raw) To: Erik Faye-Lund; +Cc: Kirill Likhodedov, Johannes Sixt, git On Thu, Oct 07, 2010 at 07:41:01PM +0200, Erik Faye-Lund wrote: > > 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 { > > This gives me a bit of a deja-vu: 1fb5fdd > > Also, fwriting like that to stdout might be a bit troublesome on > Windows because the string won't end up going through our > ANSI-emulation. I don't know enough about the Windows output code paths to comment on that. But this is almost identical to the fwrite in graph_show_commit that we use for the "rev-list --graph" show path. If there is a fix, it needs to be made to both places. -Peff ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 17:41 ` Erik Faye-Lund 2010-10-07 17:43 ` Erik Faye-Lund 2010-10-07 17:50 ` Jeff King @ 2010-10-07 17:52 ` Matthieu Moy 2010-10-07 17:53 ` Jeff King 2 siblings, 1 reply; 19+ messages in thread From: Matthieu Moy @ 2010-10-07 17:52 UTC (permalink / raw) To: kusmabite; +Cc: Jeff King, Kirill Likhodedov, Johannes Sixt, git Erik Faye-Lund <kusmabite@gmail.com> writes: > Also, fwriting like that to stdout might be a bit troublesome on > Windows because the string won't end up going through our > ANSI-emulation. I don't know which one would be most portable, but if fwrite is the problem, then printf("%*s%c", buf.buf, buf.len, info->hdr_termination); should do the trick. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 17:52 ` Matthieu Moy @ 2010-10-07 17:53 ` Jeff King 2010-10-07 18:05 ` Erik Faye-Lund 0 siblings, 1 reply; 19+ messages in thread From: Jeff King @ 2010-10-07 17:53 UTC (permalink / raw) To: Matthieu Moy; +Cc: kusmabite, Kirill Likhodedov, Johannes Sixt, git On Thu, Oct 07, 2010 at 07:52:42PM +0200, Matthieu Moy wrote: > Erik Faye-Lund <kusmabite@gmail.com> writes: > > > Also, fwriting like that to stdout might be a bit troublesome on > > Windows because the string won't end up going through our > > ANSI-emulation. > > I don't know which one would be most portable, but if fwrite is the > problem, then > > printf("%*s%c", buf.buf, buf.len, info->hdr_termination); > > should do the trick. It does work, but you have to cast the buf.len size_t to an int. -Peff ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 17:53 ` Jeff King @ 2010-10-07 18:05 ` Erik Faye-Lund 2010-10-07 18:13 ` Jeff King 0 siblings, 1 reply; 19+ messages in thread From: Erik Faye-Lund @ 2010-10-07 18:05 UTC (permalink / raw) To: Jeff King; +Cc: Matthieu Moy, Kirill Likhodedov, Johannes Sixt, git On Thu, Oct 7, 2010 at 7:53 PM, Jeff King <peff@peff.net> wrote: > On Thu, Oct 07, 2010 at 07:52:42PM +0200, Matthieu Moy wrote: > >> Erik Faye-Lund <kusmabite@gmail.com> writes: >> >> > Also, fwriting like that to stdout might be a bit troublesome on >> > Windows because the string won't end up going through our >> > ANSI-emulation. >> >> I don't know which one would be most portable, but if fwrite is the >> problem, then >> >> printf("%*s%c", buf.buf, buf.len, info->hdr_termination); >> >> should do the trick. > > It does work, but you have to cast the buf.len size_t to an int. > I'm not sure how portable it is, though. This is what K&R has to say on the matter: "characters from the string are printed until a ´\0´ is reached or until the number of characters indicated by the precision have been printed". To me it's not clear if that means that either cases can terminate the printing when the precision has been specified. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 18:05 ` Erik Faye-Lund @ 2010-10-07 18:13 ` Jeff King 2010-10-07 18:19 ` Erik Faye-Lund 0 siblings, 1 reply; 19+ messages in thread From: Jeff King @ 2010-10-07 18:13 UTC (permalink / raw) To: Erik Faye-Lund; +Cc: Matthieu Moy, Kirill Likhodedov, Johannes Sixt, git On Thu, Oct 07, 2010 at 08:05:20PM +0200, Erik Faye-Lund wrote: > >> I don't know which one would be most portable, but if fwrite is the > >> problem, then > >> > >> printf("%*s%c", buf.buf, buf.len, info->hdr_termination); > >> > >> should do the trick. > > > > It does work, but you have to cast the buf.len size_t to an int. > > > I'm not sure how portable it is, though. This is what K&R has to say > on the matter: "characters from the string are printed until a ´\0´ is > reached or until the number of characters indicated by the precision > have been printed". To me it's not clear if that means that either > cases can terminate the printing when the precision has been > specified. I take it back. It doesn't actually work (I thought I had done this just recently, but clearly not). Try: #include <stdio.h> int main() { char buf[] = "123456789"; buf[2] = '\0'; printf("%.*s\n", 5, buf); return 0; } It prints just "12" for me. -Peff ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 18:13 ` Jeff King @ 2010-10-07 18:19 ` Erik Faye-Lund 2010-10-07 18:33 ` Jeff King 0 siblings, 1 reply; 19+ messages in thread From: Erik Faye-Lund @ 2010-10-07 18:19 UTC (permalink / raw) To: Jeff King; +Cc: Matthieu Moy, Kirill Likhodedov, Johannes Sixt, git On Thu, Oct 7, 2010 at 8:13 PM, Jeff King <peff@peff.net> wrote: > On Thu, Oct 07, 2010 at 08:05:20PM +0200, Erik Faye-Lund wrote: > >> >> I don't know which one would be most portable, but if fwrite is the >> >> problem, then >> >> >> >> printf("%*s%c", buf.buf, buf.len, info->hdr_termination); >> >> >> >> should do the trick. >> > >> > It does work, but you have to cast the buf.len size_t to an int. >> > >> I'm not sure how portable it is, though. This is what K&R has to say >> on the matter: "characters from the string are printed until a ´\0´ is >> reached or until the number of characters indicated by the precision >> have been printed". To me it's not clear if that means that either >> cases can terminate the printing when the precision has been >> specified. > > I take it back. It doesn't actually work (I thought I had done this just > recently, but clearly not). Try: > > #include <stdio.h> > int main() > { > char buf[] = "123456789"; > buf[2] = '\0'; > printf("%.*s\n", 5, buf); > return 0; > } > > It prints just "12" for me. > > -Peff > Yeah. When I read K&R a bit closer, I find this: "A number specifying a minimum field width. The converted argument will be printed in a field _at least this wide_, and wider if necessary. If the converted argument has fewer characters than the field width _it will be padded_ on the left (or right, if left adjustment has been requested) to make up the field width." So it seems to me that an implementation that doesn't padd with space (which might have been the case for you here, hard to tell without inspecting stdout closer) violates K&R. There's also an example showing how the string should be padded in the early parts of the book. So we're back to not having a solution that works on Windows. And looking at our winansi emulation code, we don't have a fprintf-type code-path at all (one that takes a length), so I think fprintf is the best we can do for now. I'll see if I can come up with something a bit more long term... ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 18:19 ` Erik Faye-Lund @ 2010-10-07 18:33 ` Jeff King 2010-10-07 18:37 ` Erik Faye-Lund 0 siblings, 1 reply; 19+ messages in thread From: Jeff King @ 2010-10-07 18:33 UTC (permalink / raw) To: Erik Faye-Lund; +Cc: Matthieu Moy, Kirill Likhodedov, Johannes Sixt, git On Thu, Oct 07, 2010 at 08:19:01PM +0200, Erik Faye-Lund wrote: > Yeah. When I read K&R a bit closer, I find this: > > "A number specifying a minimum field width. The converted argument > will be printed in a field _at least this wide_, and wider if > necessary. If the converted argument has fewer characters than the > field width _it will be padded_ on the left (or right, if left > adjustment has been requested) to make up the field width." You are confusing field width (%*s) with precision (%.*s) here. C89 is pretty clear that the behavior I am seeing is mandated: 7.19.6.1, paragraph 4: An optional precision that gives ... the maximum number of bytes to be written for s conversions. 7.19.6.1, paragraph 8, item "s": ... Characters from the array are written up to (but not including) the terminating null character. If the precision is specified, no more than that many bytes are written. If the precision is not specified or is greater than the size of the array, the array shall contain a null character. so it is always about giving a maximum to print an unterminated string, or to print a partial string. But printf always stops at a NUL. -Peff ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: git log doesn't allow %x00 in custom format anymore? 2010-10-07 18:33 ` Jeff King @ 2010-10-07 18:37 ` Erik Faye-Lund 0 siblings, 0 replies; 19+ messages in thread From: Erik Faye-Lund @ 2010-10-07 18:37 UTC (permalink / raw) To: Jeff King; +Cc: Matthieu Moy, Kirill Likhodedov, Johannes Sixt, git On Thu, Oct 7, 2010 at 8:33 PM, Jeff King <peff@peff.net> wrote: > On Thu, Oct 07, 2010 at 08:19:01PM +0200, Erik Faye-Lund wrote: > >> Yeah. When I read K&R a bit closer, I find this: >> >> "A number specifying a minimum field width. The converted argument >> will be printed in a field _at least this wide_, and wider if >> necessary. If the converted argument has fewer characters than the >> field width _it will be padded_ on the left (or right, if left >> adjustment has been requested) to make up the field width." > > You are confusing field width (%*s) with precision (%.*s) here. > > C89 is pretty clear that the behavior I am seeing is mandated: > > 7.19.6.1, paragraph 4: > > An optional precision that gives ... the maximum number of bytes to > be written for s conversions. > > 7.19.6.1, paragraph 8, item "s": > > ... Characters from the array are written up to (but not including) > the terminating null character. If the precision is specified, no > more than that many bytes are written. If the precision is not > specified or is greater than the size of the array, the array shall > contain a null character. > > so it is always about giving a maximum to print an unterminated string, > or to print a partial string. But printf always stops at a NUL. > > -Peff > Indeed, thanks for clearing that up. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2010-10-07 18:37 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-10-07 11:25 git log doesn't allow %x00 in custom format anymore? Kirill Likhodedov 2010-10-07 14:10 ` Jeff King 2010-10-07 14:35 ` Kirill Likhodedov 2010-10-07 14:46 ` Jeff King 2010-10-07 15:07 ` Johannes Sixt 2010-10-07 15:18 ` Kirill Likhodedov 2010-10-07 17:29 ` Jeff King 2010-10-07 17:40 ` Matthieu Moy 2010-10-07 18:02 ` Drew Northup 2010-10-07 17:41 ` Erik Faye-Lund 2010-10-07 17:43 ` Erik Faye-Lund 2010-10-07 17:50 ` Jeff King 2010-10-07 17:52 ` Matthieu Moy 2010-10-07 17:53 ` Jeff King 2010-10-07 18:05 ` Erik Faye-Lund 2010-10-07 18:13 ` Jeff King 2010-10-07 18:19 ` Erik Faye-Lund 2010-10-07 18:33 ` Jeff King 2010-10-07 18:37 ` Erik Faye-Lund
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).