James Almer:
>
>
> On 3/16/2022 7:15 AM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Signed-off-by: James Almer <jamr...@gmail.com>
>>> ---
>>> fftools/ffmpeg.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
>>> index a98e49b775..3b625a9918 100644
>>> --- a/fftools/ffmpeg.c
>>> +++ b/fftools/ffmpeg.c
>>> @@ -2880,9 +2880,9 @@ static int init_input_stream(int ist_index,
>>> char *error, int error_len)
>>> ist->dec_ctx->opaque = ist;
>>> ist->dec_ctx->get_format = get_format;
>>> #if LIBAVCODEC_VERSION_MAJOR < 60
>>> -FF_DISABLE_DEPRECATION_WARNINGS
>>> + AV_NOWARN_DEPRECATED({
>>> ist->dec_ctx->thread_safe_callbacks = 1;
>>> -FF_ENABLE_DEPRECATION_WARNINGS
>>> + })
>>> #endif
>>> if (ist->dec_ctx->codec_id == AV_CODEC_ID_DVB_SUBTITLE &&
>>
>> AV_NOWARN_DEPRECATED currently doesn't work with Clang; so you first
>> need to find out from which version onward it supports these macros.
>
> Does not work in what way? Not compile, or just be a no-op?
> If the latter, then that's a limitation FF_DISABLE_DEPRECATION_WARNINGS
> also has for some targets. We're not going to stop using a macro just
> because it does nothing in some scenarios.
Clang takes this path in AV_NOWARN_DEPRECATED:
# define AV_NOWARN_DEPRECATED(code) code
So it is a no-op and the warning is not gone; any recent version of it
will understand the GCC pragma, so this can be rectified.
Looking at our internal deprecation macros shows that it is possible to
also support the Intel compiler.
And I really don't like that you are basically declaring Clang to be
irrelevant; it is so important that you should have tested it.
- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
