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

[nil-admirari at mailo.com]

> All these paths end up either in win32_open (in file_open.c) or in
> one of the functions mapped inside os_support.h where they are now 
> (with my submitted patchset) handled by the get_extended_win32_path()
> function, which handles all cases (e.g. forward slashes, relative paths,
> prefixed, non-prefixed, UNC, drive letters, long, short, etc.) in
> the same way as .NET does.

You are saved by the fact that nobody tries to get a path name from
a file descriptor or a FILE* (which is indeed difficult, but possible),
and then appending additional path components to such obtained path name;
thus turning a normalised path name into denormalised one.

.NET by the way, is not fully \\?\-aware. Its Path.Combine
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/IO/Path.cs
would blindly append "..\relative" to "\\?\C:\extended" turning it
into invalid "\\?\C:\extended\..\relative"

> I did that now, and you can see that it's as easy as I said.

If it's so easy, then why I'm still finding problems:
- absence of \\.\ handling: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296447.html
- stat and is_dos_path: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296448.html
- av_fopen_utf8 remnants: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296452.html