Re: git log doesn't allow %x00 in custom format anymore?
- From
Erik Faye-Lund <kusmabite@gmail.com>
- Date
- Oct 7, 2010, 18:19 UTC
- Message-ID
- <AANLkTikkZaCQKFTnQ=k2Ajp_6mVRd6mrP1P7bEASEGgd@mail.gmail.com>
- In-Reply-To
- <20101007181349.GD18518@sigill.intra.peff.net>
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...