[PATCH] non-Unicode response file support on Windows

[Rafael Espíndola]

On 23 January 2015 at 18:55, Yunzhong Gao <Yunzhong_Gao at playstation.sony.com
> wrote:

> Hi Rafael, Reid, David, thanks for the reviews. I separated the UTF-8 BOM
> part of the patch into http://reviews.llvm.org/D7156.
> It sounds like the support for Shift-JIS encoded files may be specific
> only to Sony platforms, is that true? I am kinda curious to hear from
> someone developing in Japanese environment. In writing the original patch,
> I was making the assumption that if a text file on Windows does not start
> with the BOM sequence, then it is using the current codepage. That seems to
> be the case for files created from Notepad, but of course these files can
> be created from many different sources. If this assumption is not valid,
> then I wonder what would be a good way to differentiate a UTF-8 file from a
> current-codepage one; maybe a command-line option?
> Thoughts and advice are appreciated,
>
>
Thanks for splitting the patch!

When Rafael Auler implemented the bits for *writing* response files from
clang, I think the observed behavior was

* GNU tools use the current codepage.
* MS Tools use UTF-16 only.
* Clang uses UTF-16 or UTF-8 (non-BOM)

The first part of you patch adds support for UTF-8 BOM, which I think is a
strict improvement.

The change to assume current codepage in a tool that can handle utf is what
I think is problematic, since there is no precedent for it (that I know of).

Response files are small (relative to the work they cause), so maybe one
options would be to try to check if the file is UTF-8 and fallback to
current codepage if that fails.

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150123/9cf8192c/attachment.html>