{"thread":{"id":"25379","subject":"git log doesn't allow %x00 in custom format anymore?","startedAt":"2010-10-07T11:25:29Z","lastAt":"2010-10-07T18:37:00Z","messageCount":19,"participants":["Kirill Likhodedov","Jeff King","Johannes Sixt","Matthieu Moy","Erik Faye-Lund","Drew Northup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"152870","messageId":"D9157D2F-31D5-44EF-8FB4-F0E62BBF8017@jetbrains.com","threadId":"25379","inReplyTo":null,"subject":"git log doesn't allow %x00 in custom format anymore?","fromName":"Kirill Likhodedov","fromEmail":"kirill.likhodedov@jetbrains.com","sentAt":"2010-10-07T11:25:29Z","receivedAt":"2010-10-07T11:25:29Z","isPatch":false,"sender":{"key":"kirill.likhodedov@jetbrains.com","avatar":"https://gravatar.com/avatar/9fd55d2a110e8e96deb3ed7b503d7f3b9b5b1ed5ca9ef6683c15525b11b94e63?d=mp&s=160"},"body":"\nHello,\n\nI'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:\n\nWithout null byte:\n> git log --pretty=format:%H-%ct\nOutputs something like:\n\nee5d714b95d133ff555bc8c7933dc752b5b277f5-1285954314\ncb1b9dd688d9cf155257c94e749172820b56d87a-1285954240\nb4c75be10b14d021003853e527e47ad88dc5a55b-1285833610\n1963187da6a45f898e62e4e922faac6b9382b4e4-1285807494\n\nWith a null byte\n> git log --pretty=format:%H%x00%ct\nIgnores anything appearing after the null byte:\n\nee5d714b95d133ff555bc8c7933dc752b5b277f5\ncb1b9dd688d9cf155257c94e749172820b56d87a\nb4c75be10b14d021003853e527e47ad88dc5a55b\n1963187da6a45f898e62e4e922faac6b9382b4e4\n\nOther bytes behave fine. \n\nUsing %x00 worked in Git 1.7.1 and stopped working in 1.7.2.3 (or even earlier).\n\nIs it a bug or a feature (not allowing null bytes in the custom format anymore)?\n\nIf it is a feature, the documentation should have note about it. Now it's even proposing to use %x00:\n            %x00: print a byte from a hex code\n\nThanks a lot.\n\n----------------------------------\nKirill Likhodedov\nJetBrains, Inc\nhttp://www.jetbrains.com\n\"Develop with pleasure!\"\n"},{"id":"152876","messageId":"20101007141015.GB8162@sigill.intra.peff.net","threadId":"25379","inReplyTo":"D9157D2F-31D5-44EF-8FB4-F0E62BBF8017@jetbrains.com","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-07T14:10:15Z","receivedAt":"2010-10-07T14:10:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 07, 2010 at 03:25:29PM +0400, Kirill Likhodedov wrote:\n\n> With a null byte\n> > git log --pretty=format:%H%x00%ct\n> Ignores anything appearing after the null byte:\n> \n> ee5d714b95d133ff555bc8c7933dc752b5b277f5\n> cb1b9dd688d9cf155257c94e749172820b56d87a\n> b4c75be10b14d021003853e527e47ad88dc5a55b\n> 1963187da6a45f898e62e4e922faac6b9382b4e4\n> \n> Other bytes behave fine. \n> \n> Using %x00 worked in Git 1.7.1 and stopped working in 1.7.2.3 (or even earlier).\n\nI can't reproduce using v1.7.2.3. Are you sure your pager or terminal\nisn't hiding everything after the NUL? Have you tried piping it through\n\"xxd\" or \"cat -A\"? I get:\n\n  $ git log -1 --pretty=foo%x00bar | xxd\n  0000000: 666f 6f00 6261 720a                      foo.bar.\n\n  $ git log -1 --pretty=foo%x00bar | cat -A\n  foo^@bar$\n\n> Is it a bug or a feature (not allowing null bytes in the custom format anymore)?\n\nIf it is not working, it is most definitely a bug.\n\n-Peff\n"},{"id":"152877","messageId":"5BA0D807-C5C0-4797-82CD-5D5087496D6F@jetbrains.com","threadId":"25379","inReplyTo":"20101007141015.GB8162@sigill.intra.peff.net","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Kirill Likhodedov","fromEmail":"kirill.likhodedov@jetbrains.com","sentAt":"2010-10-07T14:35:07Z","receivedAt":"2010-10-07T14:35:07Z","isPatch":false,"sender":{"key":"kirill.likhodedov@jetbrains.com","avatar":"https://gravatar.com/avatar/9fd55d2a110e8e96deb3ed7b503d7f3b9b5b1ed5ca9ef6683c15525b11b94e63?d=mp&s=160"},"body":"\nMy bad, this happens only on Windows (at least not on Mac OS X).\n\nSo it more likely is an msys porting problem or something like that, not a bug of Git itself.\nI've tested it on Windows XP SP3 with official installer for Git 1.7.2.3 and 1.7.3.1\n\nI don't think it's a terminal problem. I've tried saving the output in a file:\ngit log --pretty=format:%H%x00%ct  >a.txt\n\nI've also tried invoking the git process from a program and catching its output.\n\nHow could I report this bug? Or this message is enough? :)\n\n07.10.2010, в 18:10, Jeff King написал(а):\n\n> On Thu, Oct 07, 2010 at 03:25:29PM +0400, Kirill Likhodedov wrote:\n> \n>> With a null byte\n>>> git log --pretty=format:%H%x00%ct\n>> Ignores anything appearing after the null byte:\n>> \n>> ee5d714b95d133ff555bc8c7933dc752b5b277f5\n>> cb1b9dd688d9cf155257c94e749172820b56d87a\n>> b4c75be10b14d021003853e527e47ad88dc5a55b\n>> 1963187da6a45f898e62e4e922faac6b9382b4e4\n>> \n>> Other bytes behave fine. \n>> \n>> Using %x00 worked in Git 1.7.1 and stopped working in 1.7.2.3 (or even earlier).\n> \n> I can't reproduce using v1.7.2.3. Are you sure your pager or terminal\n> isn't hiding everything after the NUL? Have you tried piping it through\n> \"xxd\" or \"cat -A\"? I get:\n> \n>  $ git log -1 --pretty=foo%x00bar | xxd\n>  0000000: 666f 6f00 6261 720a                      foo.bar.\n> \n>  $ git log -1 --pretty=foo%x00bar | cat -A\n>  foo^@bar$\n> \n>> Is it a bug or a feature (not allowing null bytes in the custom format anymore)?\n> \n> If it is not working, it is most definitely a bug.\n> \n> -Peff\n\n----------------------------------\nKirill Likhodedov\nJetBrains, Inc\nhttp://www.jetbrains.com\n\"Develop with pleasure!\"\n"},{"id":"152878","messageId":"20101007144653.GA10904@sigill.intra.peff.net","threadId":"25379","inReplyTo":"5BA0D807-C5C0-4797-82CD-5D5087496D6F@jetbrains.com","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-07T14:46:53Z","receivedAt":"2010-10-07T14:46:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 07, 2010 at 06:35:07PM +0400, Kirill Likhodedov wrote:\n\n> My bad, this happens only on Windows (at least not on Mac OS X).\n> \n> So it more likely is an msys porting problem or something like that, not a bug of Git itself.\n> I've tested it on Windows XP SP3 with official installer for Git 1.7.2.3 and 1.7.3.1\n> \n> I don't think it's a terminal problem. I've tried saving the output in a file:\n> git log --pretty=format:%H%x00%ct  >a.txt\n> \n> I've also tried invoking the git process from a program and catching its output.\n> \n> How could I report this bug? Or this message is enough? :)\n\nIt might get seen here, but there is also an msysgit list:\n\n  msysgit@googlegroups.com\n\n-Peff\n"},{"id":"152880","messageId":"4CADE232.8030801@viscovery.net","threadId":"25379","inReplyTo":"5BA0D807-C5C0-4797-82CD-5D5087496D6F@jetbrains.com","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-10-07T15:07:30Z","receivedAt":"2010-10-07T15:07:30Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 10/7/2010 16:35, schrieb Kirill Likhodedov:\n> My bad, this happens only on Windows (at least not on Mac OS X).\n\nWith git rev-list, it also happens on Linux:\n\n$ git log -1 --pretty=foo%x00bar HEAD | od -c\n0000000   f   o   o  \\0   b   a   r  \\n\n0000010\n$ git rev-list -1 --pretty=foo%x00bar HEAD | od -c\n0000000   c   o   m   m   i   t       8   7   f   a   f   1   0   9   0\n0000020   5   d   1   f   8   a   b   1   e   9   a   c   2   4   c   c\n0000040   3   e   f   e   d   8   1   f   a   7   e   2   9   6   7  \\n\n0000060   f   o   o  \\n\n0000064\n$ git version\ngit version 1.7.3.67.gcc234\n\n-- Hannes\n"},{"id":"152882","messageId":"FF2FF369-0B1C-457E-A86E-8651BF0A82CB@jetbrains.com","threadId":"25379","inReplyTo":"4CADE232.8030801@viscovery.net","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Kirill Likhodedov","fromEmail":"kirill.likhodedov@jetbrains.com","sentAt":"2010-10-07T15:18:18Z","receivedAt":"2010-10-07T15:18:18Z","isPatch":false,"sender":{"key":"kirill.likhodedov@jetbrains.com","avatar":"https://gravatar.com/avatar/9fd55d2a110e8e96deb3ed7b503d7f3b9b5b1ed5ca9ef6683c15525b11b94e63?d=mp&s=160"},"body":"\n> With git rev-list, it also happens on Linux:\n> \n> $ git log -1 --pretty=foo%x00bar HEAD | od -c\n> 0000000   f   o   o  \\0   b   a   r  \\n\n> 0000010\n> $ git rev-list -1 --pretty=foo%x00bar HEAD | od -c\n> 0000000   c   o   m   m   i   t       8   7   f   a   f   1   0   9   0\n> 0000020   5   d   1   f   8   a   b   1   e   9   a   c   2   4   c   c\n> 0000040   3   e   f   e   d   8   1   f   a   7   e   2   9   6   7  \\n\n> 0000060   f   o   o  \\n\n> 0000064\n> $ git version\n> git version 1.7.3.67.gcc234\n> \n\n\nHannes, \n\nThanks for pointing that out.\nI confirm that on Mac OS X that happens for rev-list as well. \n\n# git log --pretty=format:foo%x00bar HEAD -1 | od -c\n0000000   f   o   o  \\0   b   a   r\n0000007\n\n# git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c\n0000000   c   o   m   m   i   t       2   3   6   0   1   a   2   c   3\n0000020   e   4   6   4   a   4   4   7   9   f   1   7   7   4   e   3\n0000040   6   e   a   5   b   9   5   8   b   4   6   0   5   2   1  \\n\n0000060   f   o   o  \\n\n0000064\n\nAnd it's not a new issue:\n\n# git version\ngit version 1.7.1\n\nSo here's what we have now about this bug:\n1. 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).\n2. It also happens at least since 1.7.2.3 for log on Windows.\n\nSorry for giving some confusion in my previous messages.\nI probably tested 'rev-list' at the time when I've recovered the problem, but I reported it as a problem with 'log'.\n\n----------------------------------\nKirill Likhodedov\nJetBrains, Inc\nhttp://www.jetbrains.com\n\"Develop with pleasure!\"\n"},{"id":"152884","messageId":"20101007172939.GA12130@sigill.intra.peff.net","threadId":"25379","inReplyTo":"FF2FF369-0B1C-457E-A86E-8651BF0A82CB@jetbrains.com","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-07T17:29:39Z","receivedAt":"2010-10-07T17:29:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote:\n\n> Thanks for pointing that out.\n> I confirm that on Mac OS X that happens for rev-list as well. \n> \n> # git log --pretty=format:foo%x00bar HEAD -1 | od -c\n> 0000000   f   o   o  \\0   b   a   r\n> 0000007\n> \n> # git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c\n> 0000000   c   o   m   m   i   t       2   3   6   0   1   a   2   c   3\n> 0000020   e   4   6   4   a   4   4   7   9   f   1   7   7   4   e   3\n> 0000040   6   e   a   5   b   9   5   8   b   4   6   0   5   2   1  \\n\n> 0000060   f   o   o  \\n\n> 0000064\n\nUgh. Even worse, it does print with --graph, which uses a slightly\ndifferent code path.\n\n  $ git rev-list --graph -1 --format=foo%x00bar HEAD | cat -A\n  *   commit 81d866a6a213d5524ce389369377ba3529461e1b$\n  |\\  foo^@bar$\n\nI am inclined to call the rev-list behavior a bug, and the fix is\nprobably:\n\ndiff --git a/builtin/rev-list.c b/builtin/rev-list.c\nindex efe9360..3b2dca0 100644\n--- a/builtin/rev-list.c\n+++ b/builtin/rev-list.c\n@@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)\n \t\t\t}\n \t\t} else {\n \t\t\tif (revs->commit_format != CMIT_FMT_USERFORMAT ||\n-\t\t\t    buf.len)\n-\t\t\t\tprintf(\"%s%c\", buf.buf, info->hdr_termination);\n+\t\t\t    buf.len) {\n+\t\t\t\tfwrite(buf.buf, 1, buf.len, stdout);\n+\t\t\t\tputchar(info->hdr_termination);\n+\t\t\t}\n \t\t}\n \t\tstrbuf_release(&buf);\n \t} else {\n"},{"id":"152886","messageId":"vpqy6a952bh.fsf@bauges.imag.fr","threadId":"25379","inReplyTo":"20101007172939.GA12130@sigill.intra.peff.net","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-10-07T17:40:18Z","receivedAt":"2010-10-07T17:40:18Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> diff --git a/builtin/rev-list.c b/builtin/rev-list.c\n> index efe9360..3b2dca0 100644\n> --- a/builtin/rev-list.c\n> +++ b/builtin/rev-list.c\n> @@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)\n>  \t\t\t}\n>  \t\t} else {\n>  \t\t\tif (revs->commit_format != CMIT_FMT_USERFORMAT ||\n> -\t\t\t    buf.len)\n> -\t\t\t\tprintf(\"%s%c\", buf.buf, info->hdr_termination);\n> +\t\t\t    buf.len) {\n> +\t\t\t\tfwrite(buf.buf, 1, buf.len, stdout);\n> +\t\t\t\tputchar(info->hdr_termination);\n> +\t\t\t}\n>  \t\t}\n>  \t\tstrbuf_release(&buf);\n>  \t} else {\n\nSounds like a sane thing to do, yes.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"152887","messageId":"AANLkTimYVNNjhaqUHjoVOV-fQBhcENKn7cyj10qcZ+MW@mail.gmail.com","threadId":"25379","inReplyTo":"20101007172939.GA12130@sigill.intra.peff.net","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2010-10-07T17:41:01Z","receivedAt":"2010-10-07T17:41:01Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, Oct 7, 2010 at 7:29 PM, Jeff King <peff@peff.net> wrote:\n> On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote:\n>\n>> Thanks for pointing that out.\n>> I confirm that on Mac OS X that happens for rev-list as well.\n>>\n>> # git log --pretty=format:foo%x00bar HEAD -1 | od -c\n>> 0000000   f   o   o  \\0   b   a   r\n>> 0000007\n>>\n>> # git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c\n>> 0000000   c   o   m   m   i   t       2   3   6   0   1   a   2   c   3\n>> 0000020   e   4   6   4   a   4   4   7   9   f   1   7   7   4   e   3\n>> 0000040   6   e   a   5   b   9   5   8   b   4   6   0   5   2   1  \\n\n>> 0000060   f   o   o  \\n\n>> 0000064\n>\n> Ugh. Even worse, it does print with --graph, which uses a slightly\n> different code path.\n>\n>  $ git rev-list --graph -1 --format=foo%x00bar HEAD | cat -A\n>  *   commit 81d866a6a213d5524ce389369377ba3529461e1b$\n>  |\\  foo^@bar$\n>\n> I am inclined to call the rev-list behavior a bug, and the fix is\n> probably:\n>\n> diff --git a/builtin/rev-list.c b/builtin/rev-list.c\n> index efe9360..3b2dca0 100644\n> --- a/builtin/rev-list.c\n> +++ b/builtin/rev-list.c\n> @@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)\n>                        }\n>                } else {\n>                        if (revs->commit_format != CMIT_FMT_USERFORMAT ||\n> -                           buf.len)\n> -                               printf(\"%s%c\", buf.buf, info->hdr_termination);\n> +                           buf.len) {\n> +                               fwrite(buf.buf, 1, buf.len, stdout);\n> +                               putchar(info->hdr_termination);\n> +                       }\n>                }\n>                strbuf_release(&buf);\n>        } else {\n\nThis gives me a bit of a deja-vu: 1fb5fdd\n\nAlso, fwriting like that to stdout might be a bit troublesome on\nWindows because the string won't end up going through our\nANSI-emulation.\n"},{"id":"152888","messageId":"AANLkTin7pt6rr-RXVWc6YSir1KHVdTr5r3Ls+61gRGqD@mail.gmail.com","threadId":"25379","inReplyTo":"AANLkTimYVNNjhaqUHjoVOV-fQBhcENKn7cyj10qcZ+MW@mail.gmail.com","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2010-10-07T17:43:10Z","receivedAt":"2010-10-07T17:43:10Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, Oct 7, 2010 at 7:41 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:\n> On Thu, Oct 7, 2010 at 7:29 PM, Jeff King <peff@peff.net> wrote:\n>> On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote:\n>>\n>>> Thanks for pointing that out.\n>>> I confirm that on Mac OS X that happens for rev-list as well.\n>>>\n>>> # git log --pretty=format:foo%x00bar HEAD -1 | od -c\n>>> 0000000   f   o   o  \\0   b   a   r\n>>> 0000007\n>>>\n>>> # git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c\n>>> 0000000   c   o   m   m   i   t       2   3   6   0   1   a   2   c   3\n>>> 0000020   e   4   6   4   a   4   4   7   9   f   1   7   7   4   e   3\n>>> 0000040   6   e   a   5   b   9   5   8   b   4   6   0   5   2   1  \\n\n>>> 0000060   f   o   o  \\n\n>>> 0000064\n>>\n>> Ugh. Even worse, it does print with --graph, which uses a slightly\n>> different code path.\n>>\n>>  $ git rev-list --graph -1 --format=foo%x00bar HEAD | cat -A\n>>  *   commit 81d866a6a213d5524ce389369377ba3529461e1b$\n>>  |\\  foo^@bar$\n>>\n>> I am inclined to call the rev-list behavior a bug, and the fix is\n>> probably:\n>>\n>> diff --git a/builtin/rev-list.c b/builtin/rev-list.c\n>> index efe9360..3b2dca0 100644\n>> --- a/builtin/rev-list.c\n>> +++ b/builtin/rev-list.c\n>> @@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)\n>>                        }\n>>                } else {\n>>                        if (revs->commit_format != CMIT_FMT_USERFORMAT ||\n>> -                           buf.len)\n>> -                               printf(\"%s%c\", buf.buf, info->hdr_termination);\n>> +                           buf.len) {\n>> +                               fwrite(buf.buf, 1, buf.len, stdout);\n>> +                               putchar(info->hdr_termination);\n>> +                       }\n>>                }\n>>                strbuf_release(&buf);\n>>        } else {\n>\n> This gives me a bit of a deja-vu: 1fb5fdd\n>\n\nNever mind that, I'm a bit too tired and got struck with a bit of paranoia :P\n"},{"id":"152891","messageId":"20101007175048.GA18518@sigill.intra.peff.net","threadId":"25379","inReplyTo":"AANLkTimYVNNjhaqUHjoVOV-fQBhcENKn7cyj10qcZ+MW@mail.gmail.com","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-07T17:50:48Z","receivedAt":"2010-10-07T17:50:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 07, 2010 at 07:41:01PM +0200, Erik Faye-Lund wrote:\n\n> > diff --git a/builtin/rev-list.c b/builtin/rev-list.c\n> > index efe9360..3b2dca0 100644\n> > --- a/builtin/rev-list.c\n> > +++ b/builtin/rev-list.c\n> > @@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)\n> >                        }\n> >                } else {\n> >                        if (revs->commit_format != CMIT_FMT_USERFORMAT ||\n> > -                           buf.len)\n> > -                               printf(\"%s%c\", buf.buf, info->hdr_termination);\n> > +                           buf.len) {\n> > +                               fwrite(buf.buf, 1, buf.len, stdout);\n> > +                               putchar(info->hdr_termination);\n> > +                       }\n> >                }\n> >                strbuf_release(&buf);\n> >        } else {\n> \n> This gives me a bit of a deja-vu: 1fb5fdd\n> \n> Also, fwriting like that to stdout might be a bit troublesome on\n> Windows because the string won't end up going through our\n> ANSI-emulation.\n\nI don't know enough about the Windows output code paths to comment on\nthat. But this is almost identical to the fwrite in graph_show_commit\nthat we use for the \"rev-list --graph\" show path. If there is a fix, it\nneeds to be made to both places.\n\n-Peff\n"},{"id":"152892","messageId":"vpqaamp3n6d.fsf@bauges.imag.fr","threadId":"25379","inReplyTo":"AANLkTimYVNNjhaqUHjoVOV-fQBhcENKn7cyj10qcZ+MW@mail.gmail.com","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-10-07T17:52:42Z","receivedAt":"2010-10-07T17:52:42Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Erik Faye-Lund <kusmabite@gmail.com> writes:\n\n> Also, fwriting like that to stdout might be a bit troublesome on\n> Windows because the string won't end up going through our\n> ANSI-emulation.\n\nI don't know which one would be most portable, but if fwrite is the\nproblem, then\n\n  printf(\"%*s%c\", buf.buf, buf.len, info->hdr_termination);\n\nshould do the trick.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"152893","messageId":"20101007175358.GD12130@sigill.intra.peff.net","threadId":"25379","inReplyTo":"vpqaamp3n6d.fsf@bauges.imag.fr","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-07T17:53:58Z","receivedAt":"2010-10-07T17:53:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 07, 2010 at 07:52:42PM +0200, Matthieu Moy wrote:\n\n> Erik Faye-Lund <kusmabite@gmail.com> writes:\n> \n> > Also, fwriting like that to stdout might be a bit troublesome on\n> > Windows because the string won't end up going through our\n> > ANSI-emulation.\n> \n> I don't know which one would be most portable, but if fwrite is the\n> problem, then\n> \n>   printf(\"%*s%c\", buf.buf, buf.len, info->hdr_termination);\n> \n> should do the trick.\n\nIt does work, but you have to cast the buf.len size_t to an int.\n\n-Peff\n"},{"id":"152894","messageId":"1286474551.15999.9.camel@drew-northup.unet.maine.edu","threadId":"25379","inReplyTo":"vpqy6a952bh.fsf@bauges.imag.fr","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2010-10-07T18:02:31Z","receivedAt":"2010-10-07T18:02:31Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Thu, 2010-10-07 at 19:40 +0200, Matthieu Moy wrote:\n> Jeff King <peff@peff.net> writes:\n> \n> > diff --git a/builtin/rev-list.c b/builtin/rev-list.c\n> > index efe9360..3b2dca0 100644\n> > --- a/builtin/rev-list.c\n> > +++ b/builtin/rev-list.c\n> > @@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)\n> >  \t\t\t}\n> >  \t\t} else {\n> >  \t\t\tif (revs->commit_format != CMIT_FMT_USERFORMAT ||\n> > -\t\t\t    buf.len)\n> > -\t\t\t\tprintf(\"%s%c\", buf.buf, info->hdr_termination);\n> > +\t\t\t    buf.len) {\n> > +\t\t\t\tfwrite(buf.buf, 1, buf.len, stdout);\n> > +\t\t\t\tputchar(info->hdr_termination);\n> > +\t\t\t}\n> >  \t\t}\n> >  \t\tstrbuf_release(&buf);\n> >  \t} else {\n> \n> Sounds like a sane thing to do, yes.\n\nAgreed. I could have sworn that printf() used standard C-strings which\nterminate with %x00!\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"152895","messageId":"AANLkTinu6fhd9DwfJpjiaxOUu_MrTym_RepR9f44=vrv@mail.gmail.com","threadId":"25379","inReplyTo":"20101007175358.GD12130@sigill.intra.peff.net","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2010-10-07T18:05:20Z","receivedAt":"2010-10-07T18:05:20Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, Oct 7, 2010 at 7:53 PM, Jeff King <peff@peff.net> wrote:\n> On Thu, Oct 07, 2010 at 07:52:42PM +0200, Matthieu Moy wrote:\n>\n>> Erik Faye-Lund <kusmabite@gmail.com> writes:\n>>\n>> > Also, fwriting like that to stdout might be a bit troublesome on\n>> > Windows because the string won't end up going through our\n>> > ANSI-emulation.\n>>\n>> I don't know which one would be most portable, but if fwrite is the\n>> problem, then\n>>\n>>   printf(\"%*s%c\", buf.buf, buf.len, info->hdr_termination);\n>>\n>> should do the trick.\n>\n> It does work, but you have to cast the buf.len size_t to an int.\n>\n\nI'm not sure how portable it is, though. This is what K&R has to say\non the matter: \"characters from the string are printed until a ´\\0´ is\nreached or until the number of characters indicated by the precision\nhave been printed\". To me it's not clear if that means that either\ncases can terminate the printing when the precision has been\nspecified.\n"},{"id":"152897","messageId":"20101007181349.GD18518@sigill.intra.peff.net","threadId":"25379","inReplyTo":"AANLkTinu6fhd9DwfJpjiaxOUu_MrTym_RepR9f44=vrv@mail.gmail.com","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-07T18:13:49Z","receivedAt":"2010-10-07T18:13:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 07, 2010 at 08:05:20PM +0200, Erik Faye-Lund wrote:\n\n> >> I don't know which one would be most portable, but if fwrite is the\n> >> problem, then\n> >>\n> >>   printf(\"%*s%c\", buf.buf, buf.len, info->hdr_termination);\n> >>\n> >> should do the trick.\n> >\n> > It does work, but you have to cast the buf.len size_t to an int.\n> >\n> I'm not sure how portable it is, though. This is what K&R has to say\n> on the matter: \"characters from the string are printed until a ´\\0´ is\n> reached or until the number of characters indicated by the precision\n> have been printed\". To me it's not clear if that means that either\n> cases can terminate the printing when the precision has been\n> specified.\n\nI take it back. It doesn't actually work (I thought I had done this just\nrecently, but clearly not). Try:\n\n  #include <stdio.h>\n  int main()\n  {\n    char buf[] = \"123456789\";\n    buf[2] = '\\0';\n    printf(\"%.*s\\n\", 5, buf);\n    return 0;\n  }\n\nIt prints just \"12\" for me.\n\n-Peff\n"},{"id":"152899","messageId":"AANLkTikkZaCQKFTnQ=k2Ajp_6mVRd6mrP1P7bEASEGgd@mail.gmail.com","threadId":"25379","inReplyTo":"20101007181349.GD18518@sigill.intra.peff.net","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2010-10-07T18:19:01Z","receivedAt":"2010-10-07T18:19:01Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, Oct 7, 2010 at 8:13 PM, Jeff King <peff@peff.net> wrote:\n> On Thu, Oct 07, 2010 at 08:05:20PM +0200, Erik Faye-Lund wrote:\n>\n>> >> I don't know which one would be most portable, but if fwrite is the\n>> >> problem, then\n>> >>\n>> >>   printf(\"%*s%c\", buf.buf, buf.len, info->hdr_termination);\n>> >>\n>> >> should do the trick.\n>> >\n>> > It does work, but you have to cast the buf.len size_t to an int.\n>> >\n>> I'm not sure how portable it is, though. This is what K&R has to say\n>> on the matter: \"characters from the string are printed until a ´\\0´ is\n>> reached or until the number of characters indicated by the precision\n>> have been printed\". To me it's not clear if that means that either\n>> cases can terminate the printing when the precision has been\n>> specified.\n>\n> I take it back. It doesn't actually work (I thought I had done this just\n> recently, but clearly not). Try:\n>\n>  #include <stdio.h>\n>  int main()\n>  {\n>    char buf[] = \"123456789\";\n>    buf[2] = '\\0';\n>    printf(\"%.*s\\n\", 5, buf);\n>    return 0;\n>  }\n>\n> It prints just \"12\" for me.\n>\n> -Peff\n>\n\nYeah. When I read K&R a bit closer, I find this:\n\n\"A number specifying a minimum field width. The converted argument\nwill be printed in a field _at least this wide_, and wider if\nnecessary. If the converted argument has fewer characters than the\nfield width _it will be padded_ on the left (or right, if left\nadjustment has been requested) to make up the field width.\"\n\nSo it seems to me that an implementation that doesn't padd with space\n(which might have been the case for you here, hard to tell without\ninspecting stdout closer) violates K&R. There's also an example\nshowing how the string should be padded in the early parts of the\nbook.\n\nSo we're back to not having a solution that works on Windows. And\nlooking at our winansi emulation code, we don't have a fprintf-type\ncode-path at all (one that takes a length), so I think fprintf is the\nbest we can do for now.\n\nI'll see if I can come up with something a bit more long term...\n"},{"id":"152901","messageId":"20101007183342.GA20289@sigill.intra.peff.net","threadId":"25379","inReplyTo":"AANLkTikkZaCQKFTnQ=k2Ajp_6mVRd6mrP1P7bEASEGgd@mail.gmail.com","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-07T18:33:42Z","receivedAt":"2010-10-07T18:33:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 07, 2010 at 08:19:01PM +0200, Erik Faye-Lund wrote:\n\n> Yeah. When I read K&R a bit closer, I find this:\n> \n> \"A number specifying a minimum field width. The converted argument\n> will be printed in a field _at least this wide_, and wider if\n> necessary. If the converted argument has fewer characters than the\n> field width _it will be padded_ on the left (or right, if left\n> adjustment has been requested) to make up the field width.\"\n\nYou are confusing field width (%*s) with precision (%.*s) here.\n\nC89 is pretty clear that the behavior I am seeing is mandated:\n\n  7.19.6.1, paragraph 4:\n\n     An optional precision that gives ... the maximum number of bytes to\n     be written for s conversions.\n\n  7.19.6.1, paragraph 8, item \"s\":\n\n    ... Characters from the array are written up to (but not including)\n    the terminating null character. If the precision is specified, no\n    more than that many bytes are written. If the precision is not\n    specified or is greater than the size of the array, the array shall\n    contain a null character.\n\nso it is always about giving a maximum to print an unterminated string,\nor to print a partial string. But printf always stops at a NUL.\n\n-Peff\n"},{"id":"152903","messageId":"AANLkTik1yeju8Z9+EMBBTG_Dt8Z=7dMBLdX8s51zd1Wk@mail.gmail.com","threadId":"25379","inReplyTo":"20101007183342.GA20289@sigill.intra.peff.net","subject":"Re: git log doesn't allow %x00 in custom format anymore?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2010-10-07T18:37:00Z","receivedAt":"2010-10-07T18:37:00Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, Oct 7, 2010 at 8:33 PM, Jeff King <peff@peff.net> wrote:\n> On Thu, Oct 07, 2010 at 08:19:01PM +0200, Erik Faye-Lund wrote:\n>\n>> Yeah. When I read K&R a bit closer, I find this:\n>>\n>> \"A number specifying a minimum field width. The converted argument\n>> will be printed in a field _at least this wide_, and wider if\n>> necessary. If the converted argument has fewer characters than the\n>> field width _it will be padded_ on the left (or right, if left\n>> adjustment has been requested) to make up the field width.\"\n>\n> You are confusing field width (%*s) with precision (%.*s) here.\n>\n> C89 is pretty clear that the behavior I am seeing is mandated:\n>\n>  7.19.6.1, paragraph 4:\n>\n>     An optional precision that gives ... the maximum number of bytes to\n>     be written for s conversions.\n>\n>  7.19.6.1, paragraph 8, item \"s\":\n>\n>    ... Characters from the array are written up to (but not including)\n>    the terminating null character. If the precision is specified, no\n>    more than that many bytes are written. If the precision is not\n>    specified or is greater than the size of the array, the array shall\n>    contain a null character.\n>\n> so it is always about giving a maximum to print an unterminated string,\n> or to print a partial string. But printf always stops at a NUL.\n>\n> -Peff\n>\n\nIndeed, thanks for clearing that up.\n"}]}