# git log doesn't allow %x00 in custom format anymore? 19 messages from 2010-10-07 to 2010-10-07. Participants: Kirill Likhodedov, Jeff King, Johannes Sixt, Matthieu Moy, Erik Faye-Lund, Drew Northup. Thread: https://gitlist.dev/t/25379 ## Kirill Likhodedov, 2010-10-07 11:25 Subject: git log doesn't allow %x00 in custom format anymore? Message-ID: URL: https://gitlist.dev/e/D9157D2F-31D5-44EF-8FB4-F0E62BBF8017%40jetbrains.com ``` 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!" ``` ## Jeff King, 2010-10-07 14:10 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: <20101007141015.GB8162@sigill.intra.peff.net> URL: https://gitlist.dev/e/20101007141015.GB8162%40sigill.intra.peff.net In-Reply-To: ``` 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, 2010-10-07 14:35 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: <5BA0D807-C5C0-4797-82CD-5D5087496D6F@jetbrains.com> URL: https://gitlist.dev/e/5BA0D807-C5C0-4797-82CD-5D5087496D6F%40jetbrains.com In-Reply-To: <20101007141015.GB8162@sigill.intra.peff.net> ``` 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!" ``` ## Jeff King, 2010-10-07 14:46 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: <20101007144653.GA10904@sigill.intra.peff.net> URL: https://gitlist.dev/e/20101007144653.GA10904%40sigill.intra.peff.net In-Reply-To: <5BA0D807-C5C0-4797-82CD-5D5087496D6F@jetbrains.com> ``` 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 ``` ## Johannes Sixt, 2010-10-07 15:07 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: <4CADE232.8030801@viscovery.net> URL: https://gitlist.dev/e/4CADE232.8030801%40viscovery.net In-Reply-To: <5BA0D807-C5C0-4797-82CD-5D5087496D6F@jetbrains.com> ``` 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 ``` ## Kirill Likhodedov, 2010-10-07 15:18 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: URL: https://gitlist.dev/e/FF2FF369-0B1C-457E-A86E-8651BF0A82CB%40jetbrains.com In-Reply-To: <4CADE232.8030801@viscovery.net> ``` > 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!" ``` ## Jeff King, 2010-10-07 17:29 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: <20101007172939.GA12130@sigill.intra.peff.net> URL: https://gitlist.dev/e/20101007172939.GA12130%40sigill.intra.peff.net In-Reply-To: ``` 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 { ``` ## Matthieu Moy, 2010-10-07 17:40 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: URL: https://gitlist.dev/e/vpqy6a952bh.fsf%40bauges.imag.fr In-Reply-To: <20101007172939.GA12130@sigill.intra.peff.net> ``` Jeff King 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/ ``` ## Erik Faye-Lund, 2010-10-07 17:41 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: URL: https://gitlist.dev/e/AANLkTimYVNNjhaqUHjoVOV-fQBhcENKn7cyj10qcZ%2BMW%40mail.gmail.com In-Reply-To: <20101007172939.GA12130@sigill.intra.peff.net> ``` On Thu, Oct 7, 2010 at 7:29 PM, Jeff King 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. ``` ## Erik Faye-Lund, 2010-10-07 17:43 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: URL: https://gitlist.dev/e/AANLkTin7pt6rr-RXVWc6YSir1KHVdTr5r3Ls%2B61gRGqD%40mail.gmail.com In-Reply-To: ``` On Thu, Oct 7, 2010 at 7:41 PM, Erik Faye-Lund wrote: > On Thu, Oct 7, 2010 at 7:29 PM, Jeff King 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 ``` ## Jeff King, 2010-10-07 17:50 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: <20101007175048.GA18518@sigill.intra.peff.net> URL: https://gitlist.dev/e/20101007175048.GA18518%40sigill.intra.peff.net In-Reply-To: ``` 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 ``` ## Matthieu Moy, 2010-10-07 17:52 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: URL: https://gitlist.dev/e/vpqaamp3n6d.fsf%40bauges.imag.fr In-Reply-To: ``` Erik Faye-Lund 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/ ``` ## Jeff King, 2010-10-07 17:53 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: <20101007175358.GD12130@sigill.intra.peff.net> URL: https://gitlist.dev/e/20101007175358.GD12130%40sigill.intra.peff.net In-Reply-To: ``` On Thu, Oct 07, 2010 at 07:52:42PM +0200, Matthieu Moy wrote: > Erik Faye-Lund 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 ``` ## Drew Northup, 2010-10-07 18:02 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: <1286474551.15999.9.camel@drew-northup.unet.maine.edu> URL: https://gitlist.dev/e/1286474551.15999.9.camel%40drew-northup.unet.maine.edu In-Reply-To: ``` On Thu, 2010-10-07 at 19:40 +0200, Matthieu Moy wrote: > Jeff King 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 ``` ## Erik Faye-Lund, 2010-10-07 18:05 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: URL: https://gitlist.dev/e/AANLkTinu6fhd9DwfJpjiaxOUu_MrTym_RepR9f44%3Dvrv%40mail.gmail.com In-Reply-To: <20101007175358.GD12130@sigill.intra.peff.net> ``` On Thu, Oct 7, 2010 at 7:53 PM, Jeff King wrote: > On Thu, Oct 07, 2010 at 07:52:42PM +0200, Matthieu Moy wrote: > >> Erik Faye-Lund 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. ``` ## Jeff King, 2010-10-07 18:13 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: <20101007181349.GD18518@sigill.intra.peff.net> URL: https://gitlist.dev/e/20101007181349.GD18518%40sigill.intra.peff.net In-Reply-To: ``` 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 int main() { char buf[] = "123456789"; buf[2] = '\0'; printf("%.*s\n", 5, buf); return 0; } It prints just "12" for me. -Peff ``` ## Erik Faye-Lund, 2010-10-07 18:19 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: URL: https://gitlist.dev/e/AANLkTikkZaCQKFTnQ%3Dk2Ajp_6mVRd6mrP1P7bEASEGgd%40mail.gmail.com In-Reply-To: <20101007181349.GD18518@sigill.intra.peff.net> ``` On Thu, Oct 7, 2010 at 8:13 PM, Jeff King 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 >  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... ``` ## Jeff King, 2010-10-07 18:33 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: <20101007183342.GA20289@sigill.intra.peff.net> URL: https://gitlist.dev/e/20101007183342.GA20289%40sigill.intra.peff.net In-Reply-To: ``` 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 ``` ## Erik Faye-Lund, 2010-10-07 18:37 Subject: Re: git log doesn't allow %x00 in custom format anymore? Message-ID: URL: https://gitlist.dev/e/AANLkTik1yeju8Z9%2BEMBBTG_Dt8Z%3D7dMBLdX8s51zd1Wk%40mail.gmail.com In-Reply-To: <20101007183342.GA20289@sigill.intra.peff.net> ``` On Thu, Oct 7, 2010 at 8:33 PM, Jeff King 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. ```