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

[Soft Works]

> -----Original Message-----
> From: Martin Storsjö <martin at martin.st>
> Sent: Tuesday, May 24, 2022 1: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 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.
> 
> 
> I know. But you said:
> 
> > 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.
> 
> And I showed how a define can apply to only one but not the other. Which
> seemed to be news to in your prior mail.

Alright yea - thanks for pointing this out. I knew about this kind of
macros, but I hadn't taken them into account in this context because
all my attempts were focusing on the struct side and getting this
separated with typedef and #undef and those things, so it was indeed
opening up a dimension I hadn't considered.
Thanks for the example!


> Note how I also said:
> 
> "Not saying that this necessarily is the way forward, but I was just
> mentioning it as a potential option to consider."
> 
> > Your example doesn't quite match the situation.
> 
> Yes I know.

Sorry, I had understood your message in a way that you would be saying
that it would be working and just not a nice solution.


> I just brought it up as a possibly thing for discussion, and you derailed
> it by discussing whether it even works. 

Nah - I meant whether it works for the given situation, I had no doubt
that your example is working as-is.

 
> >> 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).
> 
> Yes, it is possible to build it with Clang without any custom extra flags
> to enable nondefault modes. In fact, it's tested continuously on FATE too:
> 
> http://fate.ffmpeg.org/history.cgi?slot=x86_64-mingw32-clang-trunk
> 
> Also for other architectures, e.g.:
> 
> http://fate.ffmpeg.org/history.cgi?slot=aarch64-mingw32-clang-trunk


OK, thanks for the pointers. I'm not sure whether it would be 
acceptable to require this compilation flag for Windows builds?

Can you think of any other ideas?

Thank you very much,
softworkz