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

[Martin Storsjö]

On Tue, 24 May 2022, Soft Works wrote:

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

I would very much prefer not to require adding -fms-extensions when 
building with Clang - that option unlocks a lot of stuff that we generally 
shouldn't be enabling.

> Can you think of any other ideas?

Right now, mainly doing a #define ff_stat_struct which would require 
updating the calling code. It's not ideal but worse things have been done 
anyway (there's not that many stat calls).

I was exploring the idea of just redefining the struct, but e.g. "typedef 
struct _stati64 win32_stat", but that only works when referring to the 
type as "win32_stat", not "struct win32_stat". So that doesn't seem like a 
good path forward either.

I'd prefer to slow down and think more about other alternatives here, 
rather than rushing forward with adding -fms-extensions.


Also note that currently, we don't even have a proper automatic redirect 
from stat to win32_stat, see the ifdef in libavformat/file.c. So this is 
new development, or, raising the bar even further, in one sense.


// Martin