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

[nil-admirari at mailo.com]

> Paths are strings.

In other languages, paths are represented with classes, e.g. std::filesystem::path in C++
or pathlib.Path in Python. In C classes have to be emulated with structs and functions.
Even plain strings would've been OK to represent paths, if there was a set of functions
everyone uses for path operations, but there is none. Which brings us to your second question.

> It needs to be found out why it was added to decide in which way it
> can be adjusted.

Backward to forward slash adjustment is there from the very beginning:
https://github.com/FFmpeg/FFmpeg/commit/1b30e4f5865260323da5232174fc68d6cc283f45.

Apparently it's needed for path concatenation, which is implemented with snprintf,
whose pattern uses / as a separator even on Windows:
https://github.com/FFmpeg/FFmpeg/blame/master/fftools/cmdutils.c#L843.

Now back to classes. If there was a Path class, you could've changed the constructor
and the path concat operation to normalise the path and prepend it with \\?\
when it exceeds MAX_PATH, which is what you want me to do. Two places only
(maybe some more), and the entire application becomes long-path aware.

But there is no Path class. Instead there are 587 occurrences of snprintf, each of which
potentially does path concat. snprintf is not alone, strcat and the likes can also be used
for path concat.

These hundreds of places have to be examined and potentially changed to prepend \\?\.
And a couple dozen of places will surely be missed in the process.

And all that is touted as being somehow better than changing a single manifest.