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

Soft Works softworkz at hotmail.com
Tue May 24 14:15:31 EEST 2022



> -----Original Message-----
> From: Martin Storsjö <martin at martin.st>
> Sent: Tuesday, May 24, 2022 12:26 PM
> To: Soft Works <softworkz at hotmail.com>
> Cc: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>;
> Hendrik Leppkes <h.leppkes at gmail.com>
> Subject: RE: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support
> long file names on Windows
> 
> On Tue, 24 May 2022, Soft Works wrote:
> 
> >> -----Original Message-----
> >> From: Martin Storsjö <martin at martin.st>
> >> Sent: Tuesday, May 24, 2022 11:23 AM
> >> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> >> Cc: softworkz <softworkz at hotmail.com>; Hendrik Leppkes
> >> <h.leppkes at gmail.com>
> >> Subject: Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support
> >> long file names on Windows
> >>
> >> On Tue, 24 May 2022, softworkz wrote:
> >>
> >>> From: softworkz <softworkz at hotmail.com>
> >>>
> >>> Signed-off-by: softworkz <softworkz at 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?
> >
> > How could this be possible? A define is only doing string replacements,
> > so I wouldn't know how it could be restricted to the function, but
> > not the struct.
> 
> If unsure about a tool feature, please try it out for yourself.

I did :-)
(very extensively in fact)

> Yes, a
> define is only a string replacement, but a define with parameters only
> matches the string occurs with parenthesis afterwards. 

Yes, that's true, but we need to rename both, the function and the
struct, not just the function.


Your example doesn't quite match the situation.

// Let's start with the pre-requisites which cannot be changed
// Posix definitions (stat.h)
struct stat {
 	int a, b, c;
};

// This is the regular definition
int stat(char *fileName, struct stat *par)

// With your define, we replace the function, but not the 
// struct. So we would call the WinAPI function with 
// the wrong struct.
#define stat(a, b) win32_stat(a, b)

// I don't know why you have this in your example at
// this place. It comes from some include file and
// it is not the one we need to use.
// if you mean to redefine it here: that was my previous
// approach. You need to copy the struct (but rename it)
struct stat {
 	int a, b, c;
};

// ----------------- other example:

// This function needs to call the windows function,
// so we cannot use the regular stat struct as parameter
void win32_stat(struct stat *st, const char* filename);



> So here, the stat -> win32_stat rewrite only applied on the function
> declaration and call, but not on the structs.

Exactly, but the struct must be rewritten as well and this is not
possible. 

Neither this:

#define stat _stati64
#define stat(a, b) win32_stat(a, b)

nor this:

#define stat(a, b) win32_stat(a, b)
#define stat _stati64

is working (yes, I tried ;-)

> This, as the article itself clearly declares, is a C language extension.
> GCC allows it in mingw mode

Yes I had read about that.

> but Clang doesn't. (It's possible to use it
> in Clang too if you enable it with -fms-extensions though.)

Is it possible to compile ffmpeg for Windows using Clang?
And if yes, does it even work without that flag?
(assuming it was introduced in order to be able to 
compile Windows stuff).


Thanks again,
sw


More information about the ffmpeg-devel mailing list