Jeff King <peff@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html