Skip to content
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

Windows paths #11

Closed
DanieleDiBenedetto opened this issue Apr 7, 2020 · 1 comment · Fixed by #13
Closed

Windows paths #11

DanieleDiBenedetto opened this issue Apr 7, 2020 · 1 comment · Fixed by #13

Comments

@DanieleDiBenedetto
Copy link
Collaborator

DanieleDiBenedetto commented Apr 7, 2020

  • Add support to be able to parse Windows paths;
@DanieleDiBenedetto DanieleDiBenedetto self-assigned this Apr 7, 2020
@DanieleDiBenedetto
Copy link
Collaborator Author

DanieleDiBenedetto commented Apr 13, 2020

For C++ FFI it seems that it's necessary to separate the way on how paths are parsed depending if you are on Windows or *nix operating systems. The reason is that the OsStr implementation:

  • On POSIX systems, boils down to &[u8], because POSIX functions accept and return byte strings;
  • On Windows, OsStr can be thought of as an &[u16], because Win32 Unicode functions accept and return strings as arrays of 16-bit units.

The usage of CStr to parse the path doesn't solve the problem because it assumes an UTF-8 encoding.

This may seem a weird edge case, in which a Windows string is not UTF-8 encodable, but can happen quite easily for any user with a non latin alphabet.

The approach to be followed in this situation should be similar to ZCash's one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant