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

[Martin Storsjö]

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).

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