-
Notifications
You must be signed in to change notification settings - Fork 128
Ensure long paths are handled correctly in calls to Win32 APIs #423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@swift-ci test |
|
Same approach as in apple/swift-system#226 |
compnerd
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the FSProxy is better adjusted to simply use Foundation's FileManager for these operations rather than re-implementing them.
|
Sure, I can do that for the FSProxy bits. Still need our own copy of "withNTPathRepresentation" for LoadLibraryW and any other Win32 APIs we might need to directly call in future which don't have Foundation analogues. I also fixed up the path handling in Foundation itself, take a look: swiftlang/swift-foundation#1257 |
bfb3b33 to
664c7d7
Compare
|
Moved the FSProxy changes into #427, as far as existing code goes, this is now just the one-line change to LoadLibraryW. |
|
@swift-ci test |
664c7d7 to
acc4472
Compare
|
@swift-ci test |
Use the same technique being proposed in SwiftSystem and partly-implemented in Foundation. As a follow-on change, we also need to stop using POSIX filesystem APIs, which are not Unicode or long path aware.
acc4472 to
3403a24
Compare
|
@swift-ci test |
Use the same technique being proposed in SwiftSystem and partly-implemented in Foundation.
As a follow-on change, we also need to stop using POSIX filesystem APIs, which are not Unicode or long path aware.