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

_wfopen support #3234

Closed
Nekto89 opened this issue Dec 19, 2022 · 7 comments · Fixed by #3293
Closed

_wfopen support #3234

Nekto89 opened this issue Dec 19, 2022 · 7 comments · Fixed by #3293

Comments

@Nekto89
Copy link

Nekto89 commented Dec 19, 2022

On Windows it is important to use UTF-16 file paths for opening files (at least until recent versions that allow using UTF-8 locale for WinAPI).

std::fstream has overload for std::wstring
for std::FILE* there is Windows-specific "_wfopen" method as a replacement for standard std::fopen.

Is it possible to provide a way to use fmt::output_file with UTF-16 encoded filepath?

@vitaut
Copy link
Contributor

vitaut commented Dec 20, 2022

Supporting UTF-16 in a portable way is problematic but we could replace sopen_s with _wopen in

https://github.com/fmtlib/fmt/blob/master/src/os.cc#L224

This will allow passing UTF-8 paths. A PR to do this would be welcome.

@nenin-sc
Copy link

This will allow passing UTF-8 paths.

Is it possible just transfer a handle to already opened file?

@vitaut
Copy link
Contributor

vitaut commented Jan 31, 2023

Is it possible just transfer a handle to already opened file?

It is not possible with the current API.

@Fros1er
Copy link
Contributor

Fros1er commented Feb 5, 2023

I'd like to work on this.
My current idea is adding a new ctor file(wcstring_view path, int oflag);, meanwhile cast UTF-8 path to UTF-16 in original ctor.
I wonder if it's a proper way to deal with the problem.

@vitaut
Copy link
Contributor

vitaut commented Feb 5, 2023

Converting UTF-8 to UTF-16 and invoking _wopen on Windows makes sense but I don't think we should be adding a new ctor.

@Fros1er
Copy link
Contributor

Fros1er commented Feb 5, 2023

Converting UTF-8 to UTF-16 and invoking _wopen on Windows makes sense but I don't think we should be adding a new ctor.

Maybe sometimes only wchar_t * is available. Converting from UTF-16 to UTF-8 then convert it back seems a little weird.

Not sure if this is a common situation. I'll just start with no extra ctor.

@vitaut
Copy link
Contributor

vitaut commented Feb 5, 2023

I think it would be OK to add a static "factory" function with the name that indicates that it is Windows-specific, e.g. open_windows_file, that takes a wide filename and returns file.

Fros1er added a commit to Fros1er/fmt that referenced this issue Feb 6, 2023
Fros1er added a commit to Fros1er/fmt that referenced this issue Feb 6, 2023
Fros1er added a commit to Fros1er/fmt that referenced this issue Feb 6, 2023
Fros1er added a commit to Fros1er/fmt that referenced this issue Feb 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants