On Tue, Dec 5, 2017 at 5:25 PM, James Almer <jamr...@gmail.com> wrote:
> On 12/5/2017 1:13 PM, Hendrik Leppkes wrote:
>> On Tue, Dec 5, 2017 at 3:20 PM, James Almer <jamr...@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.
>
I don't know why atomic_compare_exchange* was implemented as a static
function and all types defined to the same type, instead of a macro
(like the GCC emulation).
In C++ you would use templates to handle all types, in C .. not sure
such mechanics exist.
- Hendrik
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
