[FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename, file_open: Support long file names on Windows

[nil-admirari at mailo.com]

> 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