[FFmpeg-devel] [PATCH 2/2] avformat/os_support: Support long file names on Windows

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of nil-
> admirari at mailo.com
> Sent: Sunday, May 15, 2022 9:13 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/os_support: Support
> long file names on Windows
> 
> > diff --git a/libavformat/os_support.h b/libavformat/os_support.h
> 
> In addition to what you've already added, this file defines stat as:
> 
> #ifdef _WIN32
> ...
> #  ifdef stat
> #   undef stat
> #  endif
> #  define stat _stati64
> ...
> 
> which is
> 1. not wide-char aware (_wstati64 does exist)
> 2. not long path aware.

That's a good point, even though plain stat is used in 2 cases only.
We already have win32_stat, but what's a bit tricky is that the 
struct that this function takes as a parameter is named the same 
as the function itself.

Now I have repeated the definition of 'struct stat' as 
'struct win32_stat', but maybe someone can come up with a better way.
Would you have any idea perhaps?


> Also there is a function:
> 
> static inline int is_dos_path(const char *path)
> {
> #if HAVE_DOS_PATHS
>     if (path[0] && path[1] == ':')
>         return 1;
> #endif
>     return 0;
> }
> 
> Now, DOS paths C:... end up being \\?\C:.... Are you sure it won't
> break something down the line?

The prefixing of paths is always done right before calling any of
the Windows APIs. Original strings are never modified like this.
You can be sure, because all those operations are done on
WCHAR strings only.

You could ask the question only about the case where a user might 
supply a path that is prefixed already, but when we look at the 
only(!) usage of this function then it is about handling URL and 
checking URL paths and a path starting with \\?\ wouldn't be
valid in a URL anyway.
So I don't think that this is of any concern, but it was a good
point to verify this.

Thanks for the review!

softworkz