[FFmpeg-devel] [PATCH] fix MSVC compilation errors

[James Almer]

On 12/5/2017 1:13 PM, Hendrik Leppkes wrote:
> On Tue, Dec 5, 2017 at 3:20 PM, James Almer <jamrial at gmail.com> wrote:
>> On 12/4/2017 8:31 PM, Mateusz wrote:
>>> After some tests:
>>> 1) #undef far
>>> after #include <windows.h> is wrong -- in oleauto.h is declaration
>>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>>> and 'FAR' is defined as 'far' which is define as empty.
>>>
>>> 2) #undef near
>>> after #include <windows.h> works in ffmpeg but is danger -- see 1)
>>>
>>> 3) after
>>> git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
>>> git revert 590136e78da3d091ea99ab5432543d47a559a461
>>> and patch
>>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>>> -    MXFPackage packages[2] = {};
>>> +    MXFPackage packages[2] = {{NULL}};
>>> VS 2017 can compile ffmpeg and fate stops at audiomatch-nero-16000-mono-he-m4a
>>> (without reverting 590136e hangs at api-flac-test.exe)
>>>
>>> 4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
>>> we can apply this patch and
>>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>>> index baf09119fe..b34a3803b8 100644
>>> --- a/libavcodec/utils.c
>>> +++ b/libavcodec/utils.c
>>> @@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
>>>
>>>  int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>>>  {
>>> -    _Bool exp = 0;
>>> +    atomic_bool exp = 0;
>>>      if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>>>          return 0;
>>>
>>> @@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>>>
>>>  int ff_unlock_avcodec(const AVCodec *codec)
>>>  {
>>> -    _Bool exp = 1;
>>> +    atomic_bool exp = 1;
>>
>> No, these are not meant to be atomic.
>>
> 
> int will also not work, since you would pass a pointer to an int to
> something that expects a pointer to intptr_t.
> 
> - Hendrik

So it's not a problem of _Bool being undefined in msvc? Sounds like the
win32 stdatomic.h wrapper are not correct, then. This was not an issue
with the old lavu wrapper.

Why does it use intptr_t at all for that matter? Why not the types the
gcc wrapper uses?