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

On Thu, Oct 7, 2010 at 8:13 PM, Jeff King [off-list ref] wrote:

On Thu, Oct 07, 2010 at 08:05:20PM +0200, Erik Faye-Lund wrote:

quoted

quoted

quoted

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...