threads / discuss / 25379

git log doesn't allow %x00 in custom format anymore?

Subject: git log doesn't allow %x00 in custom format anymore?

## tl;dr

19 messages between Oct 7, 2010 and Oct 7, 2010.

replies: 18people: 6as markdown or json

Kirill Likhodedov· Oct 7, 2010, 11:25 UTC · lore
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· Oct 7, 2010, 14:10 UTC · re: Kirill Likhodedov · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, Oct 07, 2010 at 03:25:29PM +0400, Kirill Likhodedov wrote:
Show 12 quoted lines
> 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· Oct 7, 2010, 14:35 UTC · re: Jeff King · lore

Re: git log doesn't allow %x00 in custom format anymore?

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 написал(а):
Show 30 quoted lines
> 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· Oct 7, 2010, 14:46 UTC · re: Kirill Likhodedov · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, Oct 07, 2010 at 06:35:07PM +0400, Kirill Likhodedov wrote:
Show 11 quoted lines
> 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· Oct 7, 2010, 15:07 UTC · re: Kirill Likhodedov · lore

Re: git log doesn't allow %x00 in custom format anymore?

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· Oct 7, 2010, 15:18 UTC · re: Johannes Sixt · lore

Re: git log doesn't allow %x00 in custom format anymore?

Show 14 quoted lines
> 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· Oct 7, 2010, 17:29 UTC · re: Kirill Likhodedov · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote:
Show 13 quoted lines
> 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· Oct 7, 2010, 17:40 UTC · re: Jeff King · lore

Re: git log doesn't allow %x00 in custom format anymore?

Jeff King <peff@peff.net> writes:
Show 17 quoted lines
> 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/
Drew Northup· Oct 7, 2010, 18:02 UTC · re: Matthieu Moy · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, 2010-10-07 at 19:40 +0200, Matthieu Moy wrote:
Show 21 quoted lines
> 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
Erik Faye-Lund· Oct 7, 2010, 17:41 UTC · re: Jeff King · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, Oct 7, 2010 at 7:29 PM, Jeff King <peff@peff.net> wrote:
Show 43 quoted lines
> 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· Oct 7, 2010, 17:43 UTC · re: Erik Faye-Lund · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, Oct 7, 2010 at 7:41 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
Show 47 quoted lines
> 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
Jeff King· Oct 7, 2010, 17:50 UTC · re: Erik Faye-Lund · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, Oct 07, 2010 at 07:41:01PM +0200, Erik Faye-Lund wrote:
Show 23 quoted lines
> > 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· Oct 7, 2010, 17:52 UTC · re: Erik Faye-Lund · lore

Re: git log doesn't allow %x00 in custom format anymore?

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/
Jeff King· Oct 7, 2010, 17:53 UTC · re: Matthieu Moy · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, Oct 07, 2010 at 07:52:42PM +0200, Matthieu Moy wrote:
Show 12 quoted lines
> 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
Erik Faye-Lund· Oct 7, 2010, 18:05 UTC · re: Jeff King · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, Oct 7, 2010 at 7:53 PM, Jeff King <peff@peff.net> wrote:
Show 17 quoted lines
> 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.

Jeff King· Oct 7, 2010, 18:13 UTC · re: Erik Faye-Lund · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, Oct 07, 2010 at 08:05:20PM +0200, Erik Faye-Lund wrote:
Show 15 quoted lines
> >> 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
Erik Faye-Lund· Oct 7, 2010, 18:19 UTC · re: Jeff King · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, Oct 7, 2010 at 8:13 PM, Jeff King <peff@peff.net> wrote:
Show 34 quoted lines
> 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...
Jeff King· Oct 7, 2010, 18:33 UTC · re: Erik Faye-Lund · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, Oct 07, 2010 at 08:19:01PM +0200, Erik Faye-Lund wrote:
Show 7 quoted lines
> 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· Oct 7, 2010, 18:37 UTC · re: Jeff King · lore

Re: git log doesn't allow %x00 in custom format anymore?

On Thu, Oct 7, 2010 at 8:33 PM, Jeff King <peff@peff.net> wrote:
Show 32 quoted lines
> 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.

← back to recent threads