[FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.

[Andreas Rheinhardt]

Rémi Denis-Courmont:
> 
> 
> Le 7 février 2024 23:19:41 GMT+02:00, James Almer <jamrial at gmail.com> a écrit :
>> On 2/7/2024 6:10 PM, Cosmin Stejerean via ffmpeg-devel wrote:
>>>
>>>
>>>> On Feb 7, 2024, at 11:27 AM, Lynne <dev at lynne.ee> wrote:
>>>>
>>>>>>
>>>>>> As a compromise, we could start requiring C11 now, and C17 in 7.1.
>>>>>> Or does anyone still care about compilers without even c11 support?
>>>>>>
>>>>>
>>>>> How about C11 now and C17 in a year with ffmpeg 8?
>>>>>
>>>>
>>>> Do you have setups and reasons why you can't update them
>>>> that don't support C17 or are you speculating?
>>>
>>> I don't have any personal reasons why I can't support C17 immediately, but C11 now / C17 in a year seems like an approach more likely to find consensus than C17 immediately (or bumping to C17 in a minor release). It was also roughly the approach proposed in person at FOSDEM.
>>
>> What are the fixes in c17 that we would benefit from, that compilers from before 2017 would be affected by?
> 
> Besides editorial corrections with no practical impact, C17 allows initialising atomics directly, without ATOMIC_VAR_INIT. This shouldn't be a problem for any real C11 compiler, but I haven't checked.
> 
> Then it also allows atomic load from const-qualified pointers. I don't know if this is relevant to FFmpeg.
> 

There are some places where we had to add casts to avoid this
restriction, see e.g. line 2626 in hevcdec.c or line 180 in refstruct.c.
Michael has some ancient Clang toolchain that breaks if this is not
done; if C17 is required, that toolchain will no longer be supported.

- Andreas