search for: bryceco

Displaying 18 results from an estimated 18 matches for "bryceco".

Did you mean: bryce
2011 Oct 03
5
[LLVMdev] [cfe-dev] Unicode path handling on Windows
...wlower doesn't seem to work with my test string in Cyrillic. This function does locale-specific conversion, is this what we want? > > Here's the whole thing, with all the calls to ::stat replaced with llvm::sys::fs::Stat. > > On Fri, Sep 30, 2011 at 8:04 PM, Bryce Cogswell <bryceco at gmail.com> wrote: > You can use _iswupper and _towlower instead of CharLowerBuffW. They don't require windows.h and work with /Za. > > On Sep 30, 2011, at 12:24 AM, Nikola Smiljanic wrote: > >> I tried to do the conversion to lowercase inside GetFullPath by adding an a...
2011 Oct 03
0
[LLVMdev] [cfe-dev] Unicode path handling on Windows
CharLowerW does the right thing. But I still need Windows.h to use it :) On Mon, Oct 3, 2011 at 8:43 PM, Bryce Cogswell <bryceco at gmail.com> wrote: > Locale-specific is not what we want, but I don't believe Windows exposes an > alternative API that does what we want. (Does CharLower give a different > answer than tolower?) > > However, looking over the FileManager code a little more I'm not even...
2011 Oct 03
1
[LLVMdev] [cfe-dev] Unicode path handling on Windows
On Oct 3, 2011, at 11:53 AM, Aaron Ballman wrote: > On Mon, Oct 3, 2011 at 1:43 PM, Bryce Cogswell <bryceco at gmail.com> wrote: >> However, looking over the FileManager code a little more I'm not even sure >> using the path is the best solution, it seems it would be better to use >> inode like the unix code does. Windows doesn't support inode (the s_ino >> field in sta...
2011 Oct 03
2
[LLVMdev] [cfe-dev] Unicode path handling on Windows
...t sure what locale that would have to be, but it needs to match whatever NTFS uses for its $upcase file. On Oct 3, 2011, at 12:19 PM, Nikola Smiljanic wrote: > CharLowerW does the right thing. But I still need Windows.h to use it :) > > On Mon, Oct 3, 2011 at 8:43 PM, Bryce Cogswell <bryceco at gmail.com> wrote: > Locale-specific is not what we want, but I don't believe Windows exposes an alternative API that does what we want. (Does CharLower give a different answer than tolower?) > > However, looking over the FileManager code a little more I'm not even sure using...
2011 Sep 30
2
[LLVMdev] [cfe-dev] Unicode path handling on Windows
...cess to CharLowerBuffW. I need Windows.h for this function but when I try to include it I get a bunch of errors because Language Extensions are disabled, /Za switch. Do I just enable them and include Windows.h inside and #ifdef section? > > On Thu, Sep 29, 2011 at 7:57 AM, Bryce Cogswell <bryceco at gmail.com> wrote: > I agree they are broken on all platforms. However, FileManager.cpp already contains an #if WIN32 conditional around the code calling LowercaseString, so you can use MultiByteToWideChar and CharLowerBuffW directly there, and not call the LowercaseString function. I don...
2011 Oct 04
2
[LLVMdev] [cfe-dev] Unicode path handling on Windows
...ame. 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], std::locale()); > > seems to be working just fine? > > On Mon, Oct 3, 2011 at 9:27 PM, Bryce Cogswell <bryceco at gmail.com> wrote: > Right, but maybe if you switch to using tolower_l() and pass an appropriate locale you can get it to work the same way. I'm not sure what locale that would have to be, but it needs to match whatever NTFS uses for its $upcase file. -------------- next part ---------...
2011 Oct 03
0
[LLVMdev] [cfe-dev] Unicode path handling on Windows
towlower doesn't seem to work with my test string in Cyrillic. This function does locale-specific conversion, is this what we want? Here's the whole thing, with all the calls to ::stat replaced with llvm::sys::fs::Stat. On Fri, Sep 30, 2011 at 8:04 PM, Bryce Cogswell <bryceco at gmail.com> wrote: > You can use _iswupper and _towlower instead of CharLowerBuffW. They don't > require windows.h and work with /Za. > > On Sep 30, 2011, at 12:24 AM, Nikola Smiljanic wrote: > > I tried to do the conversion to lowercase inside GetFullPath by adding an &...
2011 Sep 30
0
[LLVMdev] [cfe-dev] Unicode path handling on Windows
...is with access to CharLowerBuffW. I need Windows.h for this function but when I try to include it I get a bunch of errors because Language Extensions are disabled, /Za switch. Do I just enable them and include Windows.h inside and #ifdef section? On Thu, Sep 29, 2011 at 7:57 AM, Bryce Cogswell <bryceco at gmail.com> wrote: > I agree they are broken on all platforms. However, FileManager.cpp already > contains an #if WIN32 conditional around the code calling LowercaseString, > so you can use MultiByteToWideChar and CharLowerBuffW directly there, and > not call the LowercaseString f...
2011 Oct 03
0
[LLVMdev] [cfe-dev] Unicode path handling on Windows
On Mon, Oct 3, 2011 at 1:43 PM, Bryce Cogswell <bryceco at gmail.com> wrote: > However, looking over the FileManager code a little more I'm not even sure > using the path is the best solution, it seems it would be better to use > inode like the unix code does. Windows doesn't support inode (the s_ino > field in stat), but it does...
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 Sep 29
2
[LLVMdev] [cfe-dev] Unicode path handling on Windows
...latforms, not only Window, so I can't just #ifdef and use CharLowerBuffW. I need a portable way to convert from UTF8 to UTF16. There is set of functions inside clang/Basic/ConvertUTF, but LLVM can't depend on this. What do I do? > > On Tue, Sep 27, 2011 at 5:09 AM, Bryce Cogswell <bryceco at yahoo.com> wrote: > I think the assert you have for _stat64i32 is fine. It is a constant expression so should compile to nothing, and the chance of the definition changing is pretty much zero. > > LowercaseString appears to be used by ASM printers where the output is expected to be...
2011 Sep 30
0
[LLVMdev] [cfe-dev] Unicode path handling on Windows
...is with access to CharLowerBuffW. I need Windows.h for this function but when I try to include it I get a bunch of errors because Language Extensions are disabled, /Za switch. Do I just enable them and include Windows.h inside and #ifdef section? On Thu, Sep 29, 2011 at 7:57 AM, Bryce Cogswell <bryceco at gmail.com> wrote: > I agree they are broken on all platforms. However, FileManager.cpp already > contains an #if WIN32 conditional around the code calling LowercaseString, > so you can use MultiByteToWideChar and CharLowerBuffW directly there, and > not call the LowercaseString f...
2011 Sep 29
0
[LLVMdev] [cfe-dev] Unicode path handling on Windows
...n on all platforms, not only Window, so I can't just #ifdef and use CharLowerBuffW. I need a portable way to convert from UTF8 to UTF16. There is set of functions inside clang/Basic/ConvertUTF, but LLVM can't depend on this. What do I do? On Tue, Sep 27, 2011 at 5:09 AM, Bryce Cogswell <bryceco at yahoo.com> wrote: > I think the assert you have for _stat64i32 is fine. It is a constant > expression so should compile to nothing, and the chance of the definition > changing is pretty much zero. > > LowercaseString appears to be used by ASM printers where the output is >...
2011 Sep 07
0
[LLVMdev] [cfe-dev] Unicode path handling on Windows
...f8 in which case a lot of code would have to change because we'd have to convert from utf8 to utf16 whenever we call windows api functions. And note that ::wstat has different argument type than ::stat, and this structure is passed all around. On Wed, Sep 7, 2011 at 2:22 AM, Bryce Cogswell <bryceco at yahoo.com> wrote: > As was mentioned once before, the correct solution is to never use > multibyte anywhere. Any Windows functions that currently return multibyte > strings should be converted to their wide-string (unicode) equivalent, with > the result converted to UTF-8. > &...
2011 Oct 03
0
[LLVMdev] [cfe-dev] Unicode path handling on Windows
How about this: for (int i = 0; i != NumWChars; ++i) absPath[i] = std::tolower(absPath[i], std::locale()); seems to be working just fine? On Mon, Oct 3, 2011 at 9:27 PM, Bryce Cogswell <bryceco at gmail.com> wrote: > Right, but maybe if you switch to using tolower_l() and pass an appropriate > locale you can get it to work the same way. I'm not sure what locale that > would have to be, but it needs to match whatever NTFS uses for its $upcase > file. > --------------...
2011 Oct 04
2
[LLVMdev] [cfe-dev] Unicode path handling on Windows
On Tue, Oct 4, 2011 at 4:19 AM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > 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. Inde...
2011 Sep 07
2
[LLVMdev] [cfe-dev] Unicode path handling on Windows
As was mentioned once before, the correct solution is to never use multibyte anywhere. Any Windows functions that currently return multibyte strings should be converted to their wide-string (unicode) equivalent, with the result converted to UTF-8. > From: Nikola Smiljanic <popizdeh at gmail.com> > > I think I got it this time. I realized that ::open and ::stat work just fine with
2011 Sep 27
3
[LLVMdev] [cfe-dev] Unicode path handling on Windows
I think the assert you have for _stat64i32 is fine. It is a constant expression so should compile to nothing, and the chance of the definition changing is pretty much zero. LowercaseString appears to be used by ASM printers where the output is expected to be ASCII, and then some WIN32-conditioned code in FileManager.cpp. I hate to say it but you'll probably need to convert the UTF-8 paths to