diff mbox series

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

Message ID 20240205195802.14522-2-anton@khirnov.net
State New
Headers show
Series [FFmpeg-devel,1/2] lavc/refstruct: do not use max_align_t on MSVC | expand

Checks

Context Check Description
yinshiyou/commit_msg_loongarch64 warning The first line of the commit message must start with a context terminated by a colon and a space, for example "lavu/opt: " or "doc: ".
andriy/commit_msg_x86 warning The first line of the commit message must start with a context terminated by a colon and a space, for example "lavu/opt: " or "doc: ".
andriy/configure_x86 warning Failed to run configure

Commit Message

Anton Khirnov Feb. 5, 2024, 7:54 p.m. UTC 
It should be available in all relevant modern compilers and will allow
us to use features like anonymous unions.

Note that stdatomic.h is still emulated on MSVC, as current versions
require the /experimental:c11atomics, and do not support
ATOMIC_VAR_INIT() anyway.
---
Now moving to C17 rather than C11, as the former contains important
fixes and its support across the compilers we care about should be
similar.

Now also tested with MSVC in wine, thanks to Martin for pointing me at
https://github.com/mstorsjo/msvc-wine
---
 configure          | 23 +++++++++++------------
 doc/developer.texi | 10 ++--------
 2 files changed, 13 insertions(+), 20 deletions(-)

Comments

James Almer Feb. 5, 2024, 8:12 p.m. UTC | #1 
On 2/5/2024 4:54 PM, Anton Khirnov wrote:
> It should be available in all relevant modern compilers and will allow
> us to use features like anonymous unions.
> 
> Note that stdatomic.h is still emulated on MSVC, as current versions
> require the /experimental:c11atomics, and do not support
> ATOMIC_VAR_INIT() anyway.
> ---
> Now moving to C17 rather than C11, as the former contains important
> fixes and its support across the compilers we care about should be
> similar.
> 
> Now also tested with MSVC in wine, thanks to Martin for pointing me at
> https://github.com/mstorsjo/msvc-wine
> ---
>   configure          | 23 +++++++++++------------
>   doc/developer.texi | 10 ++--------
>   2 files changed, 13 insertions(+), 20 deletions(-)
> 
> diff --git a/configure b/configure
> index f72533b7d2..1bb9e23f19 100755
> --- a/configure
> +++ b/configure
> @@ -4705,7 +4705,7 @@ msvc_common_flags(){
>               # generic catch all at the bottom will print the original flag.
>               -Wall)                ;;
>               -Wextra)              ;;
> -            -std=c*)              ;;
> +            -std=c*)              echo /std:${flag#-std=};;
>               # Common flags
>               -fomit-frame-pointer) ;;
>               -g)                   echo -Z7 ;;
> @@ -4750,7 +4750,7 @@ icl_flags(){
>               # Despite what Intel's documentation says -Wall, which is supported
>               # on Windows, does enable remarks so disable them here.
>               -Wall)                echo $flag -Qdiag-disable:remark ;;
> -            -std=c99)             echo -Qstd=c99 ;;
> +            -std=c17)             echo -Qstd=c17 ;;
>               -flto*)               echo -ipo ;;
>           esac
>       done
> @@ -4798,7 +4798,7 @@ suncc_flags(){
>                       athlon*)                   echo -xarch=pentium_proa  ;;
>                   esac
>                   ;;
> -            -std=c99)             echo -xc99              ;;
> +            -std=c17)             echo -xc17              ;;

Does SunCC support this? Does anyone use SunCC at all?

>               -fomit-frame-pointer) echo -xregs=frameptr    ;;
>               -fPIC)                echo -KPIC -xcode=pic32 ;;
>               -W*,*)                echo $flag              ;;
> @@ -4887,8 +4887,8 @@ probe_cc(){
>           _type=suncc
>           _ident=$($_cc -V 2>&1 | head -n1 | cut -d' ' -f 2-)
>           _DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< | sed -e "1s,^.*: ,$@: ," -e "\$$!s,\$$, \\\," -e "1!s,^.*: , ," > $(@:.o=.d)'
> -        _DEPFLAGS='-xM1 -xc99'
> -        _ldflags='-std=c99'
> +        _DEPFLAGS='-xM1 -xc17'
> +        _ldflags='-std=c17'
>           _cflags_speed='-O5'
>           _cflags_size='-O5 -xspace'
>           _flags_filter=suncc_flags
> @@ -5517,21 +5517,20 @@ if test "$?" != 0; then
>       die "C compiler test failed."
>   fi
>   
> -add_cppflags -D_ISOC99_SOURCE
> +add_cppflags -D_ISOC11_SOURCE
>   add_cxxflags -D__STDC_CONSTANT_MACROS
>   check_cxxflags -std=c++11 || check_cxxflags -std=c++0x
>   
> -# some compilers silently accept -std=c11, so we also need to check that the
> +# some compilers silently accept -std=c17, so we also need to check that the
>   # version macro is defined properly
> -test_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" &&
> -    add_cflags -std=c11 ||
> -    check_cflags -std=c99
> +test_cflags_cc -std=c17 ctype.h "__STDC_VERSION__ >= 201710L" &&
> +    add_cflags -std=c17 || die "Compiler lacks C17 support"
>   
>   check_cppflags -D_FILE_OFFSET_BITS=64
>   check_cppflags -D_LARGEFILE_SOURCE
>   
> -add_host_cppflags -D_ISOC99_SOURCE
> -check_host_cflags -std=c99
> +add_host_cppflags -D_ISOC11_SOURCE
> +check_host_cflags -std=c17
>   check_host_cflags -Wall
>   check_host_cflags $host_cflags_speed
>   
> diff --git a/doc/developer.texi b/doc/developer.texi
> index eed0ee4915..6e9807aa06 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -56,14 +56,8 @@ and should try to fix issues their commit causes.
>   
>   @section Language
>   
> -FFmpeg is mainly programmed in the ISO C99 language, extended with:
> -@itemize @bullet
> -@item
> -Atomic operations from C11 @file{stdatomic.h}. They are emulated on
> -architectures/compilers that do not support them, so all FFmpeg-internal code
> -may use atomics without any extra checks. However, @file{stdatomic.h} must not
> -be included in public headers, so they stay C99-compatible.
> -@end itemize
> +FFmpeg is mainly programmed in the ISO C17 language, except for the public
> +headers which must stay C99 compatible.
>   
>   Compiler-specific extensions may be used with good reason, but must not be
>   depended on, i.e. the code must still compile and work with compilers lacking
Anton Khirnov Feb. 5, 2024, 8:13 p.m. UTC | #2 
Quoting James Almer (2024-02-05 21:12:00)
> Does SunCC support this? Does anyone use SunCC at all?

I do not know, but if it doesn't then we can drop it.
Devin Heitmueller Feb. 5, 2024, 8:13 p.m. UTC | #3 
On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov <anton@khirnov.net> wrote:
>
> It should be available in all relevant modern compilers and will allow
> us to use features like anonymous unions.

Is everybody on board with the implications for this patch in terms of
platforms we allow building on?  For example, the gcc on Centos7
doesn't support C17, and that isn't *that* old of a platform.

If all the developers agree that we won't support less than Centos8,
then so be it.  But I think this should be a conscious decision, and
we might want to reflect it in the documentation somewhere on what
major platforms/versions we expect to be able to build on.

Devin
Lynne Feb. 5, 2024, 8:20 p.m. UTC | #4 
Feb 5, 2024, 20:59 by anton@khirnov.net:

> It should be available in all relevant modern compilers and will allow
> us to use features like anonymous unions.
>
> Note that stdatomic.h is still emulated on MSVC, as current versions
> require the /experimental:c11atomics, and do not support
> ATOMIC_VAR_INIT() anyway.
> ---
> Now moving to C17 rather than C11, as the former contains important
> fixes and its support across the compilers we care about should be
> similar.
>
> Now also tested with MSVC in wine, thanks to Martin for pointing me at
> https://github.com/mstorsjo/msvc-wine
> ---
>  configure          | 23 +++++++++++------------
>  doc/developer.texi | 10 ++--------
>  2 files changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/configure b/configure
> index f72533b7d2..1bb9e23f19 100755
> --- a/configure
> +++ b/configure
> @@ -4705,7 +4705,7 @@ msvc_common_flags(){
>  # generic catch all at the bottom will print the original flag.
>  -Wall)                ;;
>  -Wextra)              ;;
> -            -std=c*)              ;;
> +            -std=c*)              echo /std:${flag#-std=};;
>  # Common flags
>  -fomit-frame-pointer) ;;
>  -g)                   echo -Z7 ;;
> @@ -4750,7 +4750,7 @@ icl_flags(){
>  # Despite what Intel's documentation says -Wall, which is supported
>  # on Windows, does enable remarks so disable them here.
>  -Wall)                echo $flag -Qdiag-disable:remark ;;
> -            -std=c99)             echo -Qstd=c99 ;;
> +            -std=c17)             echo -Qstd=c17 ;;
>  -flto*)               echo -ipo ;;
>  esac
>  done
> @@ -4798,7 +4798,7 @@ suncc_flags(){
>  athlon*)                   echo -xarch=pentium_proa  ;;
>  esac
>  ;;
> -            -std=c99)             echo -xc99              ;;
> +            -std=c17)             echo -xc17              ;;
>  -fomit-frame-pointer) echo -xregs=frameptr    ;;
>  -fPIC)                echo -KPIC -xcode=pic32 ;;
>  -W*,*)                echo $flag              ;;
> @@ -4887,8 +4887,8 @@ probe_cc(){
>  _type=suncc
>  _ident=$($_cc -V 2>&1 | head -n1 | cut -d' ' -f 2-)
>  _DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< | sed -e "1s,^.*: ,$@: ," -e "\$$!s,\$$, \\\," -e "1!s,^.*: , ," > $(@:.o=.d)'
> -        _DEPFLAGS='-xM1 -xc99'
> -        _ldflags='-std=c99'
> +        _DEPFLAGS='-xM1 -xc17'
> +        _ldflags='-std=c17'
>  _cflags_speed='-O5'
>  _cflags_size='-O5 -xspace'
>  _flags_filter=suncc_flags
> @@ -5517,21 +5517,20 @@ if test "$?" != 0; then
>  die "C compiler test failed."
>  fi
>  
> -add_cppflags -D_ISOC99_SOURCE
> +add_cppflags -D_ISOC11_SOURCE
>  add_cxxflags -D__STDC_CONSTANT_MACROS
>  check_cxxflags -std=c++11 || check_cxxflags -std=c++0x
>  
> -# some compilers silently accept -std=c11, so we also need to check that the
> +# some compilers silently accept -std=c17, so we also need to check that the
>  # version macro is defined properly
> -test_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" &&
> -    add_cflags -std=c11 ||
> -    check_cflags -std=c99
> +test_cflags_cc -std=c17 ctype.h "__STDC_VERSION__ >= 201710L" &&
> +    add_cflags -std=c17 || die "Compiler lacks C17 support"
>  
>  check_cppflags -D_FILE_OFFSET_BITS=64
>  check_cppflags -D_LARGEFILE_SOURCE
>  
> -add_host_cppflags -D_ISOC99_SOURCE
> -check_host_cflags -std=c99
> +add_host_cppflags -D_ISOC11_SOURCE
> +check_host_cflags -std=c17
>  check_host_cflags -Wall
>  check_host_cflags $host_cflags_speed
>  
> diff --git a/doc/developer.texi b/doc/developer.texi
> index eed0ee4915..6e9807aa06 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -56,14 +56,8 @@ and should try to fix issues their commit causes.
>  
>  @section Language
>  
> -FFmpeg is mainly programmed in the ISO C99 language, extended with:
> -@itemize @bullet
> -@item
> -Atomic operations from C11 @file{stdatomic.h}. They are emulated on
> -architectures/compilers that do not support them, so all FFmpeg-internal code
> -may use atomics without any extra checks. However, @file{stdatomic.h} must not
> -be included in public headers, so they stay C99-compatible.
> -@end itemize
> +FFmpeg is mainly programmed in the ISO C17 language, except for the public
> +headers which must stay C99 compatible.
>  
>  Compiler-specific extensions may be used with good reason, but must not be
>  depended on, i.e. the code must still compile and work with compilers lacking
>

Looks good to me.
Michael Niedermayer Feb. 5, 2024, 8:27 p.m. UTC | #5 
On Mon, Feb 05, 2024 at 08:54:40PM +0100, Anton Khirnov wrote:
> It should be available in all relevant modern compilers and will allow
> us to use features like anonymous unions.
> 
> Note that stdatomic.h is still emulated on MSVC, as current versions
> require the /experimental:c11atomics, and do not support
> ATOMIC_VAR_INIT() anyway.
> ---
> Now moving to C17 rather than C11, as the former contains important
> fixes and its support across the compilers we care about should be
> similar.
> 
> Now also tested with MSVC in wine, thanks to Martin for pointing me at
> https://github.com/mstorsjo/msvc-wine
> ---
>  configure          | 23 +++++++++++------------
>  doc/developer.texi | 10 ++--------
>  2 files changed, 13 insertions(+), 20 deletions(-)

please wait a bit with applying this so we understand better what it affects

thx

[...]
Anton Khirnov Feb. 5, 2024, 8:30 p.m. UTC | #6 
Quoting Devin Heitmueller (2024-02-05 21:13:22)
> On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov <anton@khirnov.net> wrote:
> >
> > It should be available in all relevant modern compilers and will allow
> > us to use features like anonymous unions.
> 
> Is everybody on board with the implications for this patch in terms of
> platforms we allow building on?  For example, the gcc on Centos7
> doesn't support C17, and that isn't *that* old of a platform.

According to Wikipedia, it's almost 10 years old. That counts as *that*
old in my book. If someone really needs current ffmpeg on such a
platform, they can still build their own compiler or cross-compile.
Anton Khirnov Feb. 5, 2024, 8:31 p.m. UTC | #7 
Quoting Michael Niedermayer (2024-02-05 21:27:27)
> please wait a bit with applying this so we understand better what it affects

Sure, but I'd like it to go in before 7.0.
James Almer Feb. 5, 2024, 8:33 p.m. UTC | #8 
On 2/5/2024 5:30 PM, Anton Khirnov wrote:
> Quoting Devin Heitmueller (2024-02-05 21:13:22)
>> On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov <anton@khirnov.net> wrote:
>>>
>>> It should be available in all relevant modern compilers and will allow
>>> us to use features like anonymous unions.
>>
>> Is everybody on board with the implications for this patch in terms of
>> platforms we allow building on?  For example, the gcc on Centos7
>> doesn't support C17, and that isn't *that* old of a platform.
> 
> According to Wikipedia, it's almost 10 years old. That counts as *that*
> old in my book. If someone really needs current ffmpeg on such a
> platform, they can still build their own compiler or cross-compile.

Not to mention EOLd and will stop being maintained in a couple months.
Devin Heitmueller Feb. 5, 2024, 8:40 p.m. UTC | #9 
On Mon, Feb 5, 2024 at 3:31 PM Anton Khirnov <anton@khirnov.net> wrote:
>
> Quoting Devin Heitmueller (2024-02-05 21:13:22)
> > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov <anton@khirnov.net> wrote:
> > >
> > > It should be available in all relevant modern compilers and will allow
> > > us to use features like anonymous unions.
> >
> > Is everybody on board with the implications for this patch in terms of
> > platforms we allow building on?  For example, the gcc on Centos7
> > doesn't support C17, and that isn't *that* old of a platform.
>
> According to Wikipedia, it's almost 10 years old. That counts as *that*
> old in my book. If someone really needs current ffmpeg on such a
> platform, they can still build their own compiler or cross-compile.

Another way to look at it is that it's what all Centos users used
until Centos8 was shipped in September 2019 (i.e. less than five years
ago).

Now I know that developers *LOVE* to use the latest whizbang language
features, but there's a reason that many projects choose to have
relatively old minimum language versions.

Now, again, if the developer community all agree that it makes sense
to stop supporting an operating system that was shipping as recently
as five years ago, then so be it.  But this sort of deprecation
shouldn't simply be the result of a single developer deciding he wants
to use anonymous unions (or some other C17 feature) and thus we drop
support for a bunch of operating system versions.

Devin
Michael Niedermayer Feb. 5, 2024, 8:45 p.m. UTC | #10 
On Mon, Feb 05, 2024 at 09:31:45PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-02-05 21:27:27)
> > please wait a bit with applying this so we understand better what it affects
> 
> Sure, but I'd like it to go in before 7.0.

This seems to break my stuff
I will upgarde my stuff but that will take time and there are many
things ATM like STF deadline and teh release, i have 0 free time

IMO you should announce droping support of compilers one release before
doing it so people have time to upgrade.

thx

[...]
Niklas Haas Feb. 5, 2024, 8:53 p.m. UTC | #11 
On Mon, 05 Feb 2024 15:13:22 -0500 Devin Heitmueller <devin.heitmueller@ltnglobal.com> wrote:
> On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov <anton@khirnov.net> wrote:
> >
> > It should be available in all relevant modern compilers and will allow
> > us to use features like anonymous unions.
> 
> Is everybody on board with the implications for this patch in terms of
> platforms we allow building on?  For example, the gcc on Centos7
> doesn't support C17, and that isn't *that* old of a platform.
> 
> If all the developers agree that we won't support less than Centos8,
> then so be it.  But I think this should be a conscious decision, and
> we might want to reflect it in the documentation somewhere on what
> major platforms/versions we expect to be able to build on.
> 
> Devin

Note that CentOS 7 stopped receiving package updates 4 years ago, and
will stop receiving security fixes in a couple of months. So this
discussion has an expiry date.

I think that having this change negatively affect somebody would require
an extremely specific set of circumstances. Most systems running such
old distros tend to be headless servers, not generally the type of
environment you'd expect somebody to be cloning the latest version of
ffmpeg and compiling it from source. And if somebody is committed enough
to attempt this anyway, they might as well also compile/download a more
up-to-date toolchain.

Many of our not-mandatory-but-typically-desirable dependencies are
already required at significantly newer versions. (For example, OpenSSL
3.0.0, required for HTTPS, is from 2021)
Niklas Haas Feb. 5, 2024, 8:55 p.m. UTC | #12 
On Mon, 05 Feb 2024 21:31:45 +0100 Anton Khirnov <anton@khirnov.net> wrote:
> Quoting Michael Niedermayer (2024-02-05 21:27:27)
> > please wait a bit with applying this so we understand better what it affects
> 
> Sure, but I'd like it to go in before 7.0.

What is the advantage to having it in 7.0?
Stefano Sabatini Feb. 5, 2024, 10:22 p.m. UTC | #13 
On date Monday 2024-02-05 21:55:04 +0100, Niklas Haas wrote:
> On Mon, 05 Feb 2024 21:31:45 +0100 Anton Khirnov <anton@khirnov.net> wrote:
> > Quoting Michael Niedermayer (2024-02-05 21:27:27)
> > > please wait a bit with applying this so we understand better what it affects
> > 
> > Sure, but I'd like it to go in before 7.0.
> 
> What is the advantage to having it in 7.0?

This would impact negatively many users stucked with older platforms,
so I suggest to make this just *after* the next major release to
minimize the impact (and I don't see any strong reason to make it
happen before).
Diederick C. Niehorster Feb. 6, 2024, 6:50 a.m. UTC | #14 
On Mon, Feb 5, 2024 at 8:59 PM Anton Khirnov <anton@khirnov.net> wrote:
> diff --git a/configure b/configure
> index f72533b7d2..1bb9e23f19 100755
> --- a/configure
> +++ b/configure
> @@ -5517,21 +5517,20 @@ if test "$?" != 0; then
>      die "C compiler test failed."
>  fi
>
> -add_cppflags -D_ISOC99_SOURCE
> +add_cppflags -D_ISOC11_SOURCE

Not an expert, should this be D_ISOC17_SOURCE? A google shows this
doesn't exist, so i guess i'm wrong. Some comment may be helpful here

>  add_cxxflags -D__STDC_CONSTANT_MACROS
>  check_cxxflags -std=c++11 || check_cxxflags -std=c++0x
>
> -# some compilers silently accept -std=c11, so we also need to check that the
> +# some compilers silently accept -std=c17, so we also need to check that the
>  # version macro is defined properly
> -test_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" &&
> -    add_cflags -std=c11 ||
> -    check_cflags -std=c99
> +test_cflags_cc -std=c17 ctype.h "__STDC_VERSION__ >= 201710L" &&
> +    add_cflags -std=c17 || die "Compiler lacks C17 support"
>
>  check_cppflags -D_FILE_OFFSET_BITS=64
>  check_cppflags -D_LARGEFILE_SOURCE
>
> -add_host_cppflags -D_ISOC99_SOURCE
> -check_host_cflags -std=c99
> +add_host_cppflags -D_ISOC11_SOURCE
> +check_host_cflags -std=c17

idem
Lynne Feb. 6, 2024, 12:03 p.m. UTC | #15 
Feb 6, 2024, 07:51 by dcnieho@gmail.com:

> On Mon, Feb 5, 2024 at 8:59 PM Anton Khirnov <anton@khirnov.net> wrote:
>
>> diff --git a/configure b/configure
>> index f72533b7d2..1bb9e23f19 100755
>> --- a/configure
>> +++ b/configure
>> @@ -5517,21 +5517,20 @@ if test "$?" != 0; then
>>  die "C compiler test failed."
>>  fi
>>
>> -add_cppflags -D_ISOC99_SOURCE
>> +add_cppflags -D_ISOC11_SOURCE
>>
>
> Not an expert, should this be D_ISOC17_SOURCE? A google shows this
> doesn't exist, so i guess i'm wrong. Some comment may be helpful here
>

C17 added no new functions that users have to opt-in to,
so there isn't a D_ISOC17_SOURCE define.
Opting into C11 is all that's needed.
Anton Khirnov Feb. 7, 2024, 9:50 a.m. UTC | #16 
Quoting Devin Heitmueller (2024-02-05 21:40:43)
> On Mon, Feb 5, 2024 at 3:31 PM Anton Khirnov <anton@khirnov.net> wrote:
> >
> > Quoting Devin Heitmueller (2024-02-05 21:13:22)
> > > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov <anton@khirnov.net> wrote:
> > > >
> > > > It should be available in all relevant modern compilers and will allow
> > > > us to use features like anonymous unions.
> > >
> > > Is everybody on board with the implications for this patch in terms of
> > > platforms we allow building on?  For example, the gcc on Centos7
> > > doesn't support C17, and that isn't *that* old of a platform.
> >
> > According to Wikipedia, it's almost 10 years old. That counts as *that*
> > old in my book. If someone really needs current ffmpeg on such a
> > platform, they can still build their own compiler or cross-compile.
> 
> Another way to look at it is that it's what all Centos users used
> until Centos8 was shipped in September 2019 (i.e. less than five years
> ago).
> 
> Now I know that developers *LOVE* to use the latest whizbang language
> features,

Could we please not have these kinds of caricatures in here? It's not
helpful.

Not to mention anonymous unions were standardized in C11 and widely
available for many years (possibly decades) before that, so it's hardly
a 'latest whizbang feature'.

> but there's a reason that many projects choose to have
> relatively old minimum language versions.
> 
> Now, again, if the developer community all agree that it makes sense
> to stop supporting an operating system that was shipping as recently
> as five years ago, then so be it.  But this sort of deprecation
> shouldn't simply be the result of a single developer deciding he wants
> to use anonymous unions (or some other C17 feature) and thus we drop
> support for a bunch of operating system versions.

In case you missed it, I didn't just randomly send this out of the blue,
it was discussed at the FOSDEM dev meeting (and before that on IRC and
the ML) and literally nobody in the room was against moving to C11.
Anton Khirnov Feb. 7, 2024, 9:53 a.m. UTC | #17 
Quoting Niklas Haas (2024-02-05 21:55:04)
> On Mon, 05 Feb 2024 21:31:45 +0100 Anton Khirnov <anton@khirnov.net> wrote:
> > Quoting Michael Niedermayer (2024-02-05 21:27:27)
> > > please wait a bit with applying this so we understand better what it affects
> > 
> > Sure, but I'd like it to go in before 7.0.
> 
> What is the advantage to having it in 7.0?

7.0 is a "big" API breaking release, while 7.1 is supposed to be a
smaller non-breaking release, so it seems better to put this kind of a
change in the former rather than the latter.
Anton Khirnov Feb. 7, 2024, 9:55 a.m. UTC | #18 
Quoting Michael Niedermayer (2024-02-05 21:45:10)
> On Mon, Feb 05, 2024 at 09:31:45PM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-02-05 21:27:27)
> > > please wait a bit with applying this so we understand better what it affects
> > 
> > Sure, but I'd like it to go in before 7.0.
> 
> This seems to break my stuff
> I will upgarde my stuff but that will take time and there are many
> things ATM like STF deadline and teh release, i have 0 free time
> 
> IMO you should announce droping support of compilers one release before
> doing it so people have time to upgrade.

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?
Devin Heitmueller Feb. 7, 2024, 4:15 p.m. UTC | #19 
Hello Anton,

On Wed, Feb 7, 2024 at 4:50 AM Anton Khirnov <anton@khirnov.net> wrote:
> > Now I know that developers *LOVE* to use the latest whizbang language
> > features,
>
> Could we please not have these kinds of caricatures in here? It's not
> helpful.

Permit me to rephrase:

In my 25+ years of experience as a full-time C/C++ developer, I have
run across many cases where a developer decided he/she/they wanted to
use some relatively new language feature, often without consideration
for the availability of compilers across popular platforms used by
users.  This is not the sort of thing that should be taken lightly,
and usually needs discussion with the wider developer community (and
in some cases the larger user community, depending on the project).
In fact, that single developer often doesn't even have a complete
picture of who is impacted by such a proposed change.

Which is why we talk about it.  Sometimes the answer is simply, "Hell
no, we're not going to continue supporting Windows 98!".  And
sometimes the answer is, "Oh wait, that means these tens of thousands
of users will need to upgrade their servers or cross-compile.  Perhaps
we shouldn't demand that of them just for the benefit of language
feature X at this time..."

> Not to mention anonymous unions were standardized in C11 and widely
> available for many years (possibly decades) before that, so it's hardly
> a 'latest whizbang feature'.

Yeah, I said "anonymous unions" because that was actually the
justification you offered for making C17 the minimum.  I wasn't
intending to offer a critique on using any specific language feature,
but rather wanted to make sure everyone agreed on the implications of
changing the minimum compiler version.

> > but there's a reason that many projects choose to have
> > relatively old minimum language versions.
> >
> > Now, again, if the developer community all agree that it makes sense
> > to stop supporting an operating system that was shipping as recently
> > as five years ago, then so be it.  But this sort of deprecation
> > shouldn't simply be the result of a single developer deciding he wants
> > to use anonymous unions (or some other C17 feature) and thus we drop
> > support for a bunch of operating system versions.
>
> In case you missed it, I didn't just randomly send this out of the blue,
> it was discussed at the FOSDEM dev meeting (and before that on IRC and
> the ML) and literally nobody in the room was against moving to C11.

Right, so like many people I'm not on the IRC 24x7, and regrettably I
couldn't make the FOSDEM meeting.  Perhaps I simply overlooked it, but
I couldn't find anything on the ML other than the patch you sent on
February 3rd changing it to C11.  Given the possible implications, I
would have expected to see a discussion on the ML.  If such a
discussion did happen on the ML and I overlooked it, then I guess it's
on me for not raising concerns earlier.

In fact, the FOSDEM discussion and the earlier patch was about C11,
which I actually don't have any objection to.  I would argue the same
discussion should be had to assess the impact and conclude whether
it's worth it, but it doesn't effect any of my use cases and (in my
opinion) there are likely to be far fewer users impacted by such a
change.

This feels like just the sort of thing the TC is meant to
discuss/resolve.  And the fact that your position as the developer
submitting the patch is that it's "no big deal" is exactly why it's
the sort of thing that needs agreement from a wider audience.

Devin



--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmueller@ltnglobal.com
Anton Khirnov Feb. 7, 2024, 4:36 p.m. UTC | #20 
Quoting Devin Heitmueller (2024-02-07 17:15:30)
> On Wed, Feb 7, 2024 at 4:50 AM Anton Khirnov <anton@khirnov.net> wrote:
> > Not to mention anonymous unions were standardized in C11 and widely
> > available for many years (possibly decades) before that, so it's hardly
> > a 'latest whizbang feature'.
> 
> Yeah, I said "anonymous unions" because that was actually the
> justification you offered for making C17 the minimum.  I wasn't
> intending to offer a critique on using any specific language feature,
> but rather wanted to make sure everyone agreed on the implications of
> changing the minimum compiler version.

You misunderstand, the argument for C17 rather than C11 has nothing to
do with anonymous unions, as they are available in both.

My original proposal was C11, but it was pointed out at FOSDEM that C17
has no new features and is pretty much just "C11 with bugfixes" - some
of them important for us - and all reasonably recent compilers should
support both. So if we are doing this at all, might as well take the
extra step. Nobody had any objections to that, which is why this patch
goes with C17.

> > > but there's a reason that many projects choose to have
> > > relatively old minimum language versions.
> > >
> > > Now, again, if the developer community all agree that it makes sense
> > > to stop supporting an operating system that was shipping as recently
> > > as five years ago, then so be it.  But this sort of deprecation
> > > shouldn't simply be the result of a single developer deciding he wants
> > > to use anonymous unions (or some other C17 feature) and thus we drop
> > > support for a bunch of operating system versions.
> >
> > In case you missed it, I didn't just randomly send this out of the blue,
> > it was discussed at the FOSDEM dev meeting (and before that on IRC and
> > the ML) and literally nobody in the room was against moving to C11.
> 
> Right, so like many people I'm not on the IRC 24x7, and regrettably I
> couldn't make the FOSDEM meeting.  Perhaps I simply overlooked it, but
> I couldn't find anything on the ML other than the patch you sent on
> February 3rd changing it to C11.  Given the possible implications, I
> would have expected to see a discussion on the ML.  If such a
> discussion did happen on the ML and I overlooked it, then I guess it's
> on me for not raising concerns earlier.
> 
> In fact, the FOSDEM discussion and the earlier patch was about C11,
> which I actually don't have any objection to.  I would argue the same
> discussion should be had to assess the impact and conclude whether
> it's worth it, but it doesn't effect any of my use cases and (in my
> opinion) there are likely to be far fewer users impacted by such a
> change.
> 
> This feels like just the sort of thing the TC is meant to
> discuss/resolve.  And the fact that your position as the developer
> submitting the patch is that it's "no big deal" is exactly why it's
> the sort of thing that needs agreement from a wider audience.

I agree that there needs to be a discussion, and this thread is
precisely the place where it's happening.

See also my other proposal to switch to C11 for now, and C17 for 7.1.
Cosmin Stejerean Feb. 7, 2024, 6:52 p.m. UTC | #21 
> On Feb 7, 2024, at 1:55 AM, Anton Khirnov <anton@khirnov.net> 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?

- Cosmin
Lynne Feb. 7, 2024, 7:27 p.m. UTC | #22 
Feb 7, 2024, 19:52 by ffmpeg-devel@ffmpeg.org:

>
>
>> On Feb 7, 2024, at 1:55 AM, Anton Khirnov <anton@khirnov.net> 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?
Cosmin Stejerean Feb. 7, 2024, 9:10 p.m. UTC | #23 
> On Feb 7, 2024, at 11:27 AM, Lynne <dev@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.

- Cosmin
James Almer Feb. 7, 2024, 9:19 p.m. UTC | #24 
On 2/7/2024 6:10 PM, Cosmin Stejerean via ffmpeg-devel wrote:
> 
> 
>> On Feb 7, 2024, at 11:27 AM, Lynne <dev@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?

And if we go with Cosmin's suggestion, we could always look for 
__STDC_VERSION__ >= 201710L where it matters until c17 becomes the 
minimum version in a year.
Lynne Feb. 7, 2024, 9:48 p.m. UTC | #25 
Feb 7, 2024, 22:11 by ffmpeg-devel@ffmpeg.org:

>
>
>> On Feb 7, 2024, at 11:27 AM, Lynne <dev@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.
>

It wasn't?
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).

I think there is consensus. No need to be careful or conservative,
this is a build-time bump. We've had those before, such as cuttting
off support for MSVC prior to 2015, and non-C99 compilers
(via the horrible C99-to-89 script).

Users who have real issues can always leave their opinion here,
and if not, we maintain FFmpeg 6 still.
Cosmin Stejerean Feb. 8, 2024, 12:36 a.m. UTC | #26 
> On Feb 7, 2024, at 1:48 PM, Lynne <dev@lynne.ee> wrote:
> 
> Feb 7, 2024, 22:11 by ffmpeg-devel@ffmpeg.org:
> 
>> 
>> 
>>> On Feb 7, 2024, at 11:27 AM, Lynne <dev@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.
>> 
> 
> It wasn't?
> 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 seemed to have consensus. Or at least that's my recollection of the in person discussion. 

- Cosmin
Jean-Baptiste Kempf Feb. 8, 2024, 4:29 a.m. UTC | #27 
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)
Rémi Denis-Courmont Feb. 8, 2024, 7:15 a.m. UTC | #28 
Le 7 février 2024 23:19:41 GMT+02:00, James Almer <jamrial@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@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 may be other small differences that I don't remember or know of.
Andreas Rheinhardt Feb. 8, 2024, 10:42 a.m. UTC | #29 
Rémi Denis-Courmont:
> 
> 
> Le 7 février 2024 23:19:41 GMT+02:00, James Almer <jamrial@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@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
Sean McGovern Feb. 8, 2024, 6:52 p.m. UTC | #30 
Hi developers,

On Wed, Feb 7, 2024, 23:30 Jean-Baptiste Kempf <jb@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.

-- Sean McGovern



>
James Almer Feb. 8, 2024, 7:05 p.m. UTC | #31 
On 2/8/2024 3:52 PM, Sean McGovern wrote:
> Hi developers,
> 
> On Wed, Feb 7, 2024, 23:30 Jean-Baptiste Kempf <jb@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.
Lynne Feb. 8, 2024, 7:46 p.m. UTC | #32 
Feb 8, 2024, 20:05 by jamrial@gmail.com:

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

We have plenty of old compilers on FATE, don't we?
I think the point of bumping the build-time requirements is to get rid of them,
and maybe we could use the chance to also get higher-quality metrics on
whether we can use the chance to reenable stuff like tree vectorization again
without old compilers miscompiling.

I could live with C11 for 7.0, but I would prefer to bump to C17 soon after
this release is made, rather than waiting for the middle of the year to have
to discuss this again.
Dominik 'Rathann' Mierzejewski Feb. 9, 2024, 11:22 a.m. UTC | #33 
On Monday, 05 February 2024 at 21:53, Niklas Haas wrote:
> On Mon, 05 Feb 2024 15:13:22 -0500 Devin Heitmueller
> <devin.heitmueller@ltnglobal.com> wrote:
> > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov <anton@khirnov.net> wrote:
> > >
> > > It should be available in all relevant modern compilers and will
> > > allow us to use features like anonymous unions.
> > 
> > Is everybody on board with the implications for this patch in terms
> > of platforms we allow building on?  For example, the gcc on Centos7
> > doesn't support C17, and that isn't *that* old of a platform.
> > 
> > If all the developers agree that we won't support less than Centos8,
> > then so be it.  But I think this should be a conscious decision, and
> > we might want to reflect it in the documentation somewhere on what
> > major platforms/versions we expect to be able to build on.
> 
> Note that CentOS 7 stopped receiving package updates 4 years ago, and
> will stop receiving security fixes in a couple of months. So this
> discussion has an expiry date.

Even so, a C17-supporting compiler (gcc 11.2.1) is available for CentOS 7
in the devtoolset-11-gcc package (from
http://mirror.centos.org/centos/7/sclo/x86_64/rh/).

Regards,
Dominik
Kevin Wheatley Feb. 9, 2024, 12:04 p.m. UTC | #34 
On Fri, Feb 9, 2024 at 11:22 AM Dominik 'Rathann' Mierzejewski
<dominik@greysector.net> wrote:
> Even so, a C17-supporting compiler (gcc 11.2.1) is available for CentOS 7
> in the devtoolset-11-gcc package (from
> http://mirror.centos.org/centos/7/sclo/x86_64/rh/).

As a 'User' of the FFmpeg project, we have a lot of CentOS/RHEL 7/etc
based headless machines which run FFmpeg and thus we compile versions
of FFmpeg on this platform. This is currently quite common across the
VFX industry as most of the industry is still in the process of moving
away from this to something more recent see https://vfxplatform.com/.

The availability of  "newer" compilers via the devtool set should make
 this proposed requirement a relatively small obstacle for building
newer versions. As such I think that communicating the proposed change
and its implications in the next release versions and the FFmpeg
website should be sufficient, if similar notes for other common
platforms could be added to the release notes/changelog then at least
for users of these Fedora/RHEL derivatives should be fine.

I'm assuming anybody able to compile a custom FFmpeg build, is also
able to arrange to install a prebuilt compiler, so as long as the
dependency doesn't bleed through to a runtime one, all should be good.

On the topic of why users may be so far behind the "current" for the
OS is down to several factors, in VFX  and animation it is not
uncommon to work upon a project for many years prior to releasing,
this means we tend to lock down software versions in use for long
periods of time (switching out compilers, libraries etc can all change
the results of computation and thus our images). Running multiple
projects at once can make changing the OS a long duration process.

We've recently seen a similar issue with vscode bumping glibc
dependencies https://github.com/microsoft/vscode/issues/203375 though
switching glibc versions is a lot more awkward than a compiler
requirement.

Kevin
diff mbox series

Patch

diff --git a/configure b/configure
index f72533b7d2..1bb9e23f19 100755
--- a/configure
+++ b/configure
@@ -4705,7 +4705,7 @@  msvc_common_flags(){
             # generic catch all at the bottom will print the original flag.
             -Wall)                ;;
             -Wextra)              ;;
-            -std=c*)              ;;
+            -std=c*)              echo /std:${flag#-std=};;
             # Common flags
             -fomit-frame-pointer) ;;
             -g)                   echo -Z7 ;;
@@ -4750,7 +4750,7 @@  icl_flags(){
             # Despite what Intel's documentation says -Wall, which is supported
             # on Windows, does enable remarks so disable them here.
             -Wall)                echo $flag -Qdiag-disable:remark ;;
-            -std=c99)             echo -Qstd=c99 ;;
+            -std=c17)             echo -Qstd=c17 ;;
             -flto*)               echo -ipo ;;
         esac
     done
@@ -4798,7 +4798,7 @@  suncc_flags(){
                     athlon*)                   echo -xarch=pentium_proa  ;;
                 esac
                 ;;
-            -std=c99)             echo -xc99              ;;
+            -std=c17)             echo -xc17              ;;
             -fomit-frame-pointer) echo -xregs=frameptr    ;;
             -fPIC)                echo -KPIC -xcode=pic32 ;;
             -W*,*)                echo $flag              ;;
@@ -4887,8 +4887,8 @@  probe_cc(){
         _type=suncc
         _ident=$($_cc -V 2>&1 | head -n1 | cut -d' ' -f 2-)
         _DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< | sed -e "1s,^.*: ,$@: ," -e "\$$!s,\$$, \\\," -e "1!s,^.*: , ," > $(@:.o=.d)'
-        _DEPFLAGS='-xM1 -xc99'
-        _ldflags='-std=c99'
+        _DEPFLAGS='-xM1 -xc17'
+        _ldflags='-std=c17'
         _cflags_speed='-O5'
         _cflags_size='-O5 -xspace'
         _flags_filter=suncc_flags
@@ -5517,21 +5517,20 @@  if test "$?" != 0; then
     die "C compiler test failed."
 fi
 
-add_cppflags -D_ISOC99_SOURCE
+add_cppflags -D_ISOC11_SOURCE
 add_cxxflags -D__STDC_CONSTANT_MACROS
 check_cxxflags -std=c++11 || check_cxxflags -std=c++0x
 
-# some compilers silently accept -std=c11, so we also need to check that the
+# some compilers silently accept -std=c17, so we also need to check that the
 # version macro is defined properly
-test_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" &&
-    add_cflags -std=c11 ||
-    check_cflags -std=c99
+test_cflags_cc -std=c17 ctype.h "__STDC_VERSION__ >= 201710L" &&
+    add_cflags -std=c17 || die "Compiler lacks C17 support"
 
 check_cppflags -D_FILE_OFFSET_BITS=64
 check_cppflags -D_LARGEFILE_SOURCE
 
-add_host_cppflags -D_ISOC99_SOURCE
-check_host_cflags -std=c99
+add_host_cppflags -D_ISOC11_SOURCE
+check_host_cflags -std=c17
 check_host_cflags -Wall
 check_host_cflags $host_cflags_speed
 
diff --git a/doc/developer.texi b/doc/developer.texi
index eed0ee4915..6e9807aa06 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -56,14 +56,8 @@  and should try to fix issues their commit causes.
 
 @section Language
 
-FFmpeg is mainly programmed in the ISO C99 language, extended with:
-@itemize @bullet
-@item
-Atomic operations from C11 @file{stdatomic.h}. They are emulated on
-architectures/compilers that do not support them, so all FFmpeg-internal code
-may use atomics without any extra checks. However, @file{stdatomic.h} must not
-be included in public headers, so they stay C99-compatible.
-@end itemize
+FFmpeg is mainly programmed in the ISO C17 language, except for the public
+headers which must stay C99 compatible.
 
 Compiler-specific extensions may be used with good reason, but must not be
 depended on, i.e. the code must still compile and work with compilers lacking