[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: Wednesday, May 11, 2022 10:57 AM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> utf8toansi
> 
> > I think that can be changed easily.
> 
> How about writing the necessary patches yourself?

I did and submitted today.


> > 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.
> 
> I haven't found path concat in these headers. What I did find,
> however,
> is the use of snprintf with forward slash separators right inside the
> #ifdef _WIN32:
> 
> #if defined(_WIN32) || defined (__ANDROID__) || defined(__DJGPP__)
>     if (fd < 0) {
>         snprintf(*filename, len, "./%sXXXXXX", prefix);
>         fd = mkstemp(*filename);
>     }
> #endif

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.


> > 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.
> 
> 587 was obtained with fgrep snprintf **/*.c | wc -l (became 588 after
> a recent pull).
> At least two of these uses of snprintf correspond to path
> concatenation,
> and have been already presented here. Not all of them do, but I have
> no interest
> in examining the other 586 cases. But if you think that it's easy,
> well go ahead.

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

IMO, submitting "competing" patches is not a nice behavior in general,
I only did that because you asked me to.
Hence, I didn't include replacements for those of your commits that I 
think are still valid; they should be merged as well, even though 
they are just covering niche cases and are not that much relevant 
to "long path support" in general, which is from my understanding 
primarily about being able to access input and output files on long 
paths rather than running ffmpeg.exe (et al.) residing at a long 
path location.

Kind regards,
softworkz