[PATCH] [3/6] Add support for non-utf8 file names in Path.inc
rnk at google.com
Mon Sep 30 12:51:24 PDT 2013
Response files generated by Visual Studio are usually UTF16-LE with a
byte-order mark, making it easy to spot them. The response file parser can
already handle that.
If they lack a BOM, we assume they are UTF-8. I don't think we want to
support any other model. Will that work for you, or is it important to be
able to produce response files with the system multi-byte encoding?
On Mon, Sep 30, 2013 at 12:34 PM, Gao, Yunzhong <
yunzhong_gao at playstation.sony.com> wrote:
> Reid's suggestion (using wmain) does seem like a neat solution; it saves
> one system-locale-to-unicode conversion.
> I will experiment with this approach later this week to see how well it
> I wonder whether the contents of a response file should be UTF8 or system
> locale encoded?
> - Gao.
> > -----Original Message-----
> > From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> > bounces at cs.uiuc.edu] On Behalf Of Rafael Espíndola
> > Sent: Monday, September 30, 2013 12:15 PM
> > To: Reid Kleckner
> > Cc: Commit Messages and Patches for LLVM;
> > reviews+D1295+public+0bd57a4d645c744a at llvm-reviews.chandlerc.com
> > Subject: Re: [PATCH] [3/6] Add support for non-utf8 file names in
> > > Yes, probably the real solution is to define wmain instead of main, so
> > > we can get our hands on Unicode paths to start with, convert that to
> > > UTF-8 internally, and go from there.
> > Agreed. We really should not try guessing the encoding.
> > Cheers,
> > Rafael
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits