On 2/8/2024 3:52 PM, Sean McGovern wrote:
Hi developers,
On Wed, Feb 7, 2024, 23:30 Jean-Baptiste Kempf <j...@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.
_______________________________________________
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".
