[FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename, file_open: 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: Friday, May 20, 2022 7:52 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename,
> file_open: Support long file names on Windows
> 
> > Yes, that's true. But there are hundreds of other things someone could
> > define which makes compilation fail.
> 
> Doesn't mean that yet another such thing should be added by incorrectly
> redefining structs already defined correctly by system headers.
> 
> > Probably you didn't spot it. It's already there:
> > # define stat win32_stat
> 
> I'm actually wondering how does it even compile. All stat structs in code
> become struct win32_stat, and all calls to stat become calls to
> win32_stat,
> which in turn wraps _wstati64. But _wstati64 does not accept struct
> win32_stat*,
> it accepts struct _stati64*. Content of these structs is probably
> identical, but
> it should not matter: C is typed nominally, not structurally.
> 
> > I don't want to say that I'd consider this to be a great solution.
> > But the problem is that the function and struct names are identical
> > and when we want to re-define/map the function, we also need to
> > provide a struct of that name because the macro-replacement can't
> > work selectively.
> 
> Doesn't mean that the should be named identically in FFmpeg code.
> Naming a struct stat and a function avpriv_stat is a reasonable choice.
> You can even define avpriv_stat with parameters the way fstat is defined:
> 
> #ifdef _WIN32
> #define avpriv_stat(f,s) win32_stat((f), (s))
> #else
> #define avpriv_stat(f,s) stat((f), (s))
> #endif

I thought the purpose of all those re-mappings would be that plain
Posix functions can still be used..?
It's already the Posix declaration where the function name 
is the same as the structure name (stat).

I'm unbiased. avpriv_stat() would be ok from my POV as well, but 
I'm not sure whether all others would agree when plain stat could
no longer be used (without breaking long filename support)?

Thanks,
softworkz