llvm dev - Sep 2011 - [LLVMdev] [cfe-dev] Unicode path handling on Windows

On Tue, Sep 6, 2011 at 11:28 PM, Nikola Smiljanic <popizdeh at gmail.com>
wrote:
> The problem is not in the functions that return multibyte strings (the
> multibyte string is coming from argv)
argv is implicitly the return from a UTF16->multibyte conversion (i.e.
it's lossy).

-Eli

So what are you exactly saying? Somebody proposed using GetCommandLine
instead of using argv directly. And what about my other points about ::open
and ::stat?

On Wed, Sep 7, 2011 at 8:52 AM, Eli Friedman <eli.friedman at gmail.com>
wrote:
> On Tue, Sep 6, 2011 at 11:28 PM, Nikola Smiljanic <popizdeh at
gmail.com>
> wrote:
> > The problem is not in the functions that return multibyte strings (the
> > multibyte string is coming from argv)
>
> argv is implicitly the return from a UTF16->multibyte conversion (i.e.
> it's lossy).
>
> -Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110907/a874c2fe/attachment.html>

On Wed, Sep 7, 2011 at 12:20 AM, Nikola Smiljanic <popizdeh at gmail.com>
wrote:
> So what are you exactly saying? Somebody proposed using GetCommandLine
> instead of using argv directly. And what about my other points about ::open
> and ::stat?
Because of the way Windows works, the only fully correct solution is
to never touch the native charset, and keep everything in UTF-8/16 all
the time.  Anything else is going to lead to bugs like "clang fails to
find my file in a directory whose name has a Greek letter in it".  If
we're going to be spending time messing with this code, we should take
the time to get it right.  If it requires some extra refactoring to
make that work, that's acceptable...

-Eli
> On Wed, Sep 7, 2011 at 8:52 AM, Eli Friedman <eli.friedman at
gmail.com> wrote:
>>
>> On Tue, Sep 6, 2011 at 11:28 PM, Nikola Smiljanic <popizdeh at
gmail.com>
>> wrote:
>> > The problem is not in the functions that return multibyte strings
(the
>> > multibyte string is coming from argv)
>>
>> argv is implicitly the return from a UTF16->multibyte conversion
(i.e.
>> it's lossy).
>>
>> -Eli
>
>