Re: [PATCH] rev-list: handle %x00 NUL in user format

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 13, 2010, 21:58 UTC
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.