search for: uni_replacement_char

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> ------------...