Details
- Reviewers
amccarth EricWF ldionne - Group Reviewers
Restricted Project - Commits
- rG0c71c914faa3: [libcxx] Implement the current_path function for windows
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/src/filesystem/operations.cpp | ||
---|---|---|
1139 | Is _wgetcwd the right choice here? Shouldn't this instead go straight to Windows with GetCurrentDirectoryW so it doesn't take a dependence on MSVC's CRT? |
libcxx/src/filesystem/operations.cpp | ||
---|---|---|
1139 | I guess we could do that as well; we still have a few other calls that go through the CRT (in the FileDescriptor helper class further up in the file, used for file copying), and in this case, there's no other practical limitation in _wgetcwd that we'd get around, other than cleanliness. (Calling GetCurrentDirectoryW takes two calls and manual allocation inbetween, unless we want to hardcode a PATH_MAX allocation, but I'd rather move away from such specific limits.) But yeah I can change it if you still prefer that. |
Your call on using the CRT. I was under the mistaken impression that libcxx would implement both the standard C++ library as well as the CRT.
Moved to a getcwd helper in posix_compat.h, change existing code to use path::value_type instead of hardcoded char.
Reworked this patch to allow two use patterns of the POSIX getcwd() function - in strict POSIX getcwd(), it has to be given a preallocated buffer of a fixed size - but at least glibc and Darwin libc's (and windows) allow passing nullptr, to let the function allocate a suitably large buffer. For now I only use that codepath for windows (to reduce the risk of anything breaking due to this patch), but we could enable it on POSIX systems where we know it's supported as a later feature.
Is _wgetcwd the right choice here? Shouldn't this instead go straight to Windows with GetCurrentDirectoryW so it doesn't take a dependence on MSVC's CRT?