Displaying 4 results from an estimated 4 matches for "uni_replacement_char".
2011 Oct 04
2
[LLVMdev] [cfe-dev] Unicode path handling on Windows
...F32)0x80) { bytesToWrite = 1;
+ } else if (ch < (UTF32)0x800) { bytesToWrite = 2;
+ } else if (ch < (UTF32)0x10000) { bytesToWrite = 3;
+ } else if (ch < (UTF32)0x110000) { bytesToWrite = 4;
+ } else { bytesToWrite = 3;
+ ch = UNI_REPLACEMENT_CHAR;
+ }
I think this should be formatted more like this to meet our coding
standards (but am not 100% sure, so I will defer to others):
if (ch < (UTF32)0x80)
bytesToWrite = 1;
else if (ch < (UTF32)0x800)
bytesToWrite = 2;
...
else
ch = UNI_REPLACEMENT_CHAR;
Those are the only mino...
2011 Oct 04
0
[LLVMdev] [cfe-dev] Unicode path handling on Windows
In that case I think that this is it :)
On Tue, Oct 4, 2011 at 8:24 AM, Bryce Cogswell <bryceco at gmail.com> wrote:
> That should be fine. I don't believe the concern about performing a
> char-by-char conversion is valid; for example the NTFS-3G driver uses a
> simplistic upcase table and seems to work fine. I suspect Windows does the
> same.
>
>
-------------- next
2011 Oct 04
2
[LLVMdev] [cfe-dev] Unicode path handling on Windows
That should be fine. I don't believe the concern about performing a char-by-char conversion is valid; for example the NTFS-3G driver uses a simplistic upcase table and seems to work fine. I suspect Windows does the same.
On Oct 3, 2011, at 1:12 PM, Nikola Smiljanic wrote:
> How about this:
>
> for (int i = 0; i != NumWChars; ++i)
> absPath[i] = std::tolower(absPath[i],
2011 Oct 04
0
[LLVMdev] [cfe-dev] Unicode path handling on Windows
...ixed
>
> I think this should be formatted more like this to meet our coding
> standards (but am not 100% sure, so I will defer to others):
>
> if (ch < (UTF32)0x80)
> bytesToWrite = 1;
> else if (ch < (UTF32)0x800)
> bytesToWrite = 2;
> ...
> else
> ch = UNI_REPLACEMENT_CHAR;
>
>
I haven't touched this code. I only took the function out of the section
that was commented out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111004/84d54a66/attachment.html>
------------...