On Sat, 7 May 2022, Soft Works wrote:
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of nil-
admir...@mailo.com
Sent: Friday, May 6, 2022 6:08 PM
To: ffmpeg-devel@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
_______________________________________________
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".
