On Thu, 9 Jun 2022, Soft Works wrote:
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Martin
Storsjö
Sent: Thursday, June 9, 2022 12:10 PM
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v12 1/4] libavutil/wchar_filename.h: Add
whcartoutf8, wchartoansi and utf8toansi
On Sun, 5 Jun 2022, Nil Admirari wrote:
These functions are going to be used in libavformat/avisynth.c
and fftools/cmdutils.c to remove MAX_PATH limit.
---
libavutil/wchar_filename.h | 51 ++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
This patchset looks good to me too, thanks! If there's no more comments on
it, I'll push it later.
I missed to take another look at it.
I'm wondering why it converts wchar back to ansi instead of utf8 in 4/4 and
whether it won't fail then, when a path contains non-ANSI chars.
Yes, that's a preexisting problem there. That patch gets rid of the fixed
path lengths without touching the rest of the charset handling there.
There's paths from two sources; getenv() and from GetModuleFileName().
These are passed to plain fopen() (which uses ANSI filenames).
To make it entirely unicode compliant, we'd need to replace getenv() with
a wrapper that uses _wgetenv() and converts that to utf8, then convert the
GetModuleFileName() output to utf8 too, and switch the fopen() to
fopen_utf8.
So the patch in itself is fine - it fixes one aspect, and doesn't make the
other aspect worse.
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
