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

["Martin Storsjö" <martin@martin.st>]

On Tue, 24 May 2022, Soft Works wrote:

>> -----Original Message-----
>> From: Martin Storsjö <martin@martin.st>
>> Sent: Tuesday, May 24, 2022 12:26 PM
>> To: Soft Works <softworkz@hotmail.com>
>> Cc: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>;
>> Hendrik Leppkes <h.leppkes@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@martin.st>
>>>> Sent: Tuesday, May 24, 2022 11:23 AM
>>>> To: FFmpeg development discussions and patches <ffmpeg-
>> devel@ffmpeg.org>
>>>> Cc: softworkz <softworkz@hotmail.com>; Hendrik Leppkes
>>>> <h.leppkes@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@hotmail.com>
>>>>>
>>>>> Signed-off-by: softworkz <softworkz@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.

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.

I just brought it up as a possibly thing for discussion, and you derailed 
it by discussing whether it even works. Yes it works, but after looking 
more into it, I agree that it probably won't help in this situation.

>> 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

// 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-request@ffmpeg.org with subject "unsubscribe".