[FFmpeg-devel] [PATCH v12 1/4] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Martin
> Storsjö
> Sent: Thursday, June 9, 2022 9:09 PM
> To: FFmpeg development discussions and patches <ffmpeg-devel at 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-bounces at ffmpeg.org> On Behalf Of Martin
> >> Storsjö
> >> Sent: Thursday, June 9, 2022 12:10 PM
> >> To: FFmpeg development discussions and patches <ffmpeg-devel at 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)

Same applies to GetModuleFileNameW()
when using the wchar output - but not when using a string conversion to
an Ansi string.

> > So the patch in itself is fine - it fixes one aspect, and doesn't make the
> other aspect worse.

Wouldn't it make it worse in the case above?


Thanks,
sw