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

[Martin Storsjö]

On Sat, 7 May 2022, Soft Works wrote:

>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of nil-
>> admirari at mailo.com
>> Sent: Friday, May 6, 2022 6:08 PM
>> To: ffmpeg-devel at ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
>> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
>> utf8toansi
>>
>>>> As a matter of fact, you are. Your alternative method implies
>>>> ploughing
>>>> through hundreds of C files normalising path handling across the
>>>> entire application,
>>
>>> Almost everybody here knows that this isn't true.
>>
>> I do not. During the review of just this particular patchset it was
>> found that FFmpeg
>> sometimes uses av_fopen_utf8 and sometimes just plain fopen. Plain
>> fopens
>> were already replaced with av_fopen_utf8 and then reverted back.
>> because suddenly it turned out that av_fopen_utf8 is problematic:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295488.html.
>
> Read again. As each lib gets its own copy of file_open.c there's
> no problem using av_fopen_utf8. The concern in that message was
> about it being a public API that could be used by external callers.

No, it's not quite as simple.

Yes, each library gets its own copy of av_fopen_utf8, but fftools doesn't 
get its own copy. That's why it's a real problem.

(Secondly, one part of the trick of giving each library its own copy of is 
that avpriv_open is renamed ff_open, so that it is not an exported 
function. But in the case of av_fopen_utf8, it's an entirely public API, 
so we can't hide it.)

// Martin