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 9:09 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 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).
What I meant is the use of wchartoansi() in patch 4/4.
The current code calls GetModuleFileNameA()
the new code calls GetModuleFileNameW() and then converts the output
file name with wchartoansi().
Can we be sure that this is always the same?
Especially when the path contains non-ANSI chars?
That's something quite different. GetModuleFileNameA() will return a
valid and usable path (but it could be an 8.3 path or have some
replacement chars)
Right, I wasn't aware that the -A version would return a
guaranteed-ansi-compatible version of the filename. If that's really the
case, this patch would indeed be a minor step backwards.
// 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".
