On Tue, 24 May 2022, softworkz wrote:
From: softworkz <softwo...@hotmail.com>Signed-off-by: softworkz <softwo...@hotmail.com> --- libavformat/os_support.h | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/libavformat/os_support.h b/libavformat/os_support.h index 5e6b32d2dc..d4c07803a5 100644 --- a/libavformat/os_support.h +++ b/libavformat/os_support.h @@ -49,7 +49,13 @@ # ifdef stat # undef stat # endif -# define stat _stati64 +# define stat win32_stat + + struct win32_stat + { + struct _stati64; + };
Is it possible to work around this issue by doing "#define stat(a,b)" which only should apply on the function, not to the struct? Then we can't redirect "struct stat" into "struct _stati64" at the same time...
A safe way forward could be to switch code to just using "struct ff_stat_struct", and define ff_stat_struct to the name of the struct we exepct to use. It's not pretty, and it affects users which no longer can use the default POSIX stat form of the calls, but it would fix the issue of redirecting the struct and function separately, without needing to know what exactly is in the struct (because we really shouldn't be hardcoding/assuming that).
// Martin _______________________________________________ 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".
