> 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
