From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 13 Oct 2010 21:58:40 GMT
Subject: Re: [PATCH] rev-list: handle %x00 NUL in user format
Message-ID: <7vtykpiwkv.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20101007182542.GA20165@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> Erik mentioned a potential problem with fwrite() and the way we handle
> ANSI emulation for Windows. I think if there is a problem, then the same
> problem exists in the --graph code, and we should do this, and then fix
> both on top.

I am quite sure that --graph codepath is used a lot less often than this
codepath, and most users do not hit the problem you are fixing---that is
why it took so long to get noticed.  I think this printf() has been there
from the beginning, even though the possibility of placing a NUL in
buf.buf may have come much later, like when %x00 was introduced).

Use of fwrite() here will affect all Windows users who use color (probably
most of them), no?  It may be a deliberate regression, but it has a real
cost associated with it; it will break more usual uses on Windows to help
an obscure use case on POSIX.

As to emulating fwrite(3) on Windows, even though there are a lot of
callers of fwrite(3) that do not want the payload colored, it is probably
sufficient to check isatty(fileno(stream)) upfront like all the other
winansi_fEMULATED() functions do, and to make ansi_emulate() call the
system fwrite(3) directly.

I'll queue this patch on a side branch and I may even feel like merging it
to 'next', but we would need to hear from Windows folks how they want to
proceed soon.