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

[James Almer]

On 2/8/2024 3:52 PM, Sean McGovern wrote:
> Hi developers,
> 
> On Wed, Feb 7, 2024, 23:30 Jean-Baptiste Kempf <jb at videolan.org> wrote:
> 
>> Hello,
>>
>> On Thu, 8 Feb 2024, at 01:36, Cosmin Stejerean via ffmpeg-devel wrote:
>>>> There were simply no objections to moving to C11.
>>>> The C17 plan came about later because it has important bugfixes.
>>>> It doesn't really matter as compilers backported the new behaviour to
>> C11
>>>> (or rather, they consistently had the same behaviour, but now it became
>> a standard).
>>>>
>>>
>>> There were no objections to C11, however C17 was brought up and there
>>> were objections that it's likely too soon and I believe JB proposed
>>> holding off for a year on C17 (while adopting C11 immediately), which
>>
>> My recommendation is still this:
>> - move to C11 now
>> - activate C17 on some Fate/CI targets
>> - recommend C17 compilers modes
>> - move to C17 at this mid-year when 7.1 is branched (LTS if we follow our
>> plans)
>>
> 
> 
> I like this approach. It's a shame we can't get metrics on who might be
> genuinely affected by a direct move to C17.
> 
> I'd be more than willing to host one or more FATE nodes with C17 turned on.
> Do let me know if this is desirable.

At least for GCC, -std=c11 is the same as -std=c17 except for the 
__STDC_VERSION__ value. As in, apparently all the fixes are implemented 
either way. And as far as i understand it, we would require c11 but use 
c17 if present (Meaning, test std=c17, fallback to std=c11, abort if not 
possible), so all FATE instances using a relatively recent compiler will 
invariably use c17.

What we would need is instances with old compilers, pre-2017, to get 
actual c11 testing.