[FFmpeg-devel] [PATCH v11 1/6] 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 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.

> At least in one place backward slashes are being replaced with forward
> slashes,
> which is not compatible with \\?\.

That's the pending issue with your 4/6 which is probably ok otherwise.


> > Why should that be bad news for me?
> > Those are three very specific cases and we had already covered this.
> 
> Because none of this is covered. They are covered by my patches,
> and you're against merging them.

5/6 + 6/6 are the manifest changes
4/6 see above (forward slash replacement problem)
3/6 is pointless without 5/6
2/6 is pointless without 6/6
1/6 remaining bits can be inlined in 4/6

Kind regards,
softworkz