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

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