-
Notifications
You must be signed in to change notification settings - Fork 87
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
Supporting non-UTF-8 paths #33
Comments
Perhaps |
Thank you for the kind words! Like Freaky said, you can likely use Fuchsia does indeed have everything as UTF-8, but I'm 100% willing to add more general support. |
That sounds like a bug. |
Line 188 in e59f2c8
I mentioned |
Thanks so much, @benbrittain, for your openness towards this improvement! With that added correctness, I think this will put My thoughts are as follows:
Is there anything fundamental I am missing? I am asking because maybe we sketch out the implementation a little and attract contributors :). |
Hi @benbrittain, I think if I would hear your ideas about my initial thoughts stated above, I would consider giving the implementation a shot. That way I hope to avoid going off in the wrong direction. Thanks a lot! |
That sounds great, thank you! Regarding binary overhead, I would think that there is close to none, but then again I don't really know how |
I love
argh
for its simplicity, compile performance and leanness, and I find myself migrating more and more projects to it.Just now it became evident that despite supporting
PathBuf
in struct fields, it will always assume valid UTF-8 in the arguments it parses. This might be an assumption that holds in Fuchsia, but may make it impossible to use for general purpose linux tools that consume paths in arguments.I wonder if there is any chance to allow parsing
PathBuf
fields without making assumptions about their encoding?Thank you
PS: This question was triggered by this post on reddit/r/rust.
The text was updated successfully, but these errors were encountered: