[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: Tuesday, May 10, 2022 11:23 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> utf8toansi
> 
> > 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/1b30e4f5865260323da5232174fc68
> d6cc283f45.
> 
> 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.

I think that can be changed easily. A path using forward slashes can
still be prefixed with '\\?\', so it will just require to go through 
the few lines of code and fix cases where this might cause an issue.


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

I'm afraid, it's not clear to me what you are talking about here.

The prefixing can be implemented as a function and then be used 
in file_open.c.

Other file system related functions like mkdir, rename, rmdir, etc.
are already intercepted in os_support.h, and the prefixing can be 
applied there.

Maybe I missed some cases, I have not fully analyzed the situation,
but surely there are just a small number of places that need to 
be changed and not 587.


For the procedure of prefixing I would take a look at how it's done
in .NET. This is probably the most mature code for handling this
and might save us from dealing with issues and regressions until we 
got it right.


Kind regards,
softworkz