Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
On Fri, Feb 9, 2024 at 11:22 AM Dominik 'Rathann' Mierzejewski 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 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
On Monday, 05 February 2024 at 21:53, Niklas Haas wrote: > On Mon, 05 Feb 2024 15:13:22 -0500 Devin Heitmueller > wrote: > > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov 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 -- Fedora https://fedoraproject.org Deep in the human unconscious is a pervasive need for a logical universe that makes sense. But the real universe is always one step beyond logic. -- from "The Sayings of Muad'Dib" by the Princess Irulan ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Feb 8, 2024, 20:05 by jamr...@gmail.com: > On 2/8/2024 3:52 PM, Sean McGovern wrote: > >> Hi developers, >> >> On Wed, Feb 7, 2024, 23:30 Jean-Baptiste Kempf 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. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
On 2/8/2024 3:52 PM, Sean McGovern wrote: Hi developers, On Wed, Feb 7, 2024, 23:30 Jean-Baptiste Kempf 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Hi developers, On Wed, Feb 7, 2024, 23:30 Jean-Baptiste Kempf 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 > ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Rémi Denis-Courmont: > > > Le 7 février 2024 23:19:41 GMT+02:00, James Almer a écrit > : >> On 2/7/2024 6:10 PM, Cosmin Stejerean via ffmpeg-devel wrote: >>> >>> On Feb 7, 2024, at 11:27 AM, Lynne 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 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Le 7 février 2024 23:19:41 GMT+02:00, James Almer a écrit : >On 2/7/2024 6:10 PM, Cosmin Stejerean via ffmpeg-devel wrote: >> >> >>> On Feb 7, 2024, at 11:27 AM, Lynne 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. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
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) -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
> On Feb 7, 2024, at 1:48 PM, Lynne wrote: > > Feb 7, 2024, 22:11 by ffmpeg-devel@ffmpeg.org: > >> >> >>> On Feb 7, 2024, at 11:27 AM, Lynne 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 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Feb 7, 2024, 22:11 by ffmpeg-devel@ffmpeg.org: > > >> On Feb 7, 2024, at 11:27 AM, Lynne 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. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
On 2/7/2024 6:10 PM, Cosmin Stejerean via ffmpeg-devel wrote: On Feb 7, 2024, at 11:27 AM, Lynne 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. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
> On Feb 7, 2024, at 11:27 AM, Lynne 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 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Feb 7, 2024, 19:52 by ffmpeg-devel@ffmpeg.org: > > >> On Feb 7, 2024, at 1:55 AM, Anton Khirnov 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? ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
> On Feb 7, 2024, at 1:55 AM, Anton Khirnov 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 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Quoting Devin Heitmueller (2024-02-07 17:15:30) > On Wed, Feb 7, 2024 at 4:50 AM Anton Khirnov 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. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Hello Anton, On Wed, Feb 7, 2024 at 4:50 AM Anton Khirnov 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.heitmuel...@ltnglobal.com ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
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? -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Quoting Niklas Haas (2024-02-05 21:55:04) > On Mon, 05 Feb 2024 21:31:45 +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. > > 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 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Quoting Devin Heitmueller (2024-02-05 21:40:43) > On Mon, Feb 5, 2024 at 3:31 PM Anton Khirnov wrote: > > > > Quoting Devin Heitmueller (2024-02-05 21:13:22) > > > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov 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 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Feb 6, 2024, 07:51 by dcni...@gmail.com: > On Mon, Feb 5, 2024 at 8:59 PM Anton Khirnov 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. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
On Mon, Feb 5, 2024 at 8:59 PM Anton Khirnov 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 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
On date Monday 2024-02-05 21:55:04 +0100, Niklas Haas wrote: > On Mon, 05 Feb 2024 21:31:45 +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. > > 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). ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
On Mon, 05 Feb 2024 21:31:45 +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. What is the advantage to having it in 7.0? ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
On Mon, 05 Feb 2024 15:13:22 -0500 Devin Heitmueller wrote: > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov 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) ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
On Mon, Feb 5, 2024 at 3:31 PM Anton Khirnov wrote: > > Quoting Devin Heitmueller (2024-02-05 21:13:22) > > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov 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 -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
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 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. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
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. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Quoting Devin Heitmueller (2024-02-05 21:13:22) > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov 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 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Feb 5, 2024, 20:59 by an...@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. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov 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 -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
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. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
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 ___ 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".