[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 Soft
> Works
> Sent: Wednesday, May 11, 2022 12:59 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> utf8toansi
> 
> 
> 
> > -----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.

The logic they use is here:

https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/IO/PathHelper.Windows.cs

Probably it can be simplified a bit.

Kind regards,
softworkz