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

[nil-admirari at mailo.com]

> > 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.
At least in one place backward slashes are being replaced with forward slashes,
which is not compatible with \\?\.

But you can easily prove me wrong by showing me your patches. As a starting point:
it was already shown how LLVM prefixes paths
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295677.html.
If that functionality is to be ported into FFmpeg, where exactly should the code go?
Is there a Path struct, analogous to LLVM class, that all of FFmpeg is using?
Or FFmpeg isn't using any special structs and paths are indistinguishable
from ordinary strings?

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

> My point is very simple: It should be a solution that will always 
> work and not just sometimes.

Manifest works whether you like it or not. People without the registry setting
do not have it for the simple reason of never having to work with long paths.
And they most likely will enable it the first time such a need arises.