On Tue, Oct 25, 2022 at 10:51 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote: > > == Owner == > > * Name: [[User:fweimer| Florian Weimer]] > > * Email: [mailto:fweimer@xxxxxxxxxx| fweimer@xxxxxxxxxx] > > > > > > == Detailed Description == > > The most important change is the <b>removal of implicit function > > declarations</b>. This legacy compatibility feature causes the > > compiler to automatically supply a declaration of type `int > > function()` if `function` is undeclared, but called as a function. > > However, the implicit return type of `int` is incompatible with > > pointer-returning functions, which can lead to difficult debugging > > sessions if the compiler warning is missed, as described here: > > > > * [https://developers.redhat.com/blog/2019/04/22/implicit-function-declarations-flexs-use-of-reallocarray| > > Implicit function declarations: flex's use of "reallocarray"] > > > > On x86-64, functions returning `_Bool` called with an implicit > > declaration will also not work correctly because the return register > > value for `_Bool` functions is partially undefined (not all 32 bits in > > the implicitly declared `int` are defined). > > > > Another change for C99 is the <b>removal of implicit `int` type > > declarations</b>. For example, in the following fragment, both `i` and > > `j` are defined as `int` variables: > > > > <pre> > > static i = 1.0; > > auto j = 2.0; > > </pre> > > > > Support for this obsolete constructs is incompatible with adoption of > > type inference for `auto` definitions (which are part of C++). > > > > Neither change is trivial to implement because introducing errors for > > these constructs (as required by C99) alters the result of autoconf > > configure checks. Quite a few such checks use an implicitly declared > > `exit` function, for instance. These failures are not really related > > to the feature under test. If the build system is well written, the > > build still succeeds, the relevant features are automatically disabled > > in the test suite and removed from reference ABI lists, and it's not > > immediately apparent that feature is gone. Therefore, some care is > > needed that no such alterations happen, and packages need to be ported > > to C99. Various tools for this porting activity are being developed to > > support this proposal. Cross-distribution collaboration will help as > > well, sharing patches and insights. > > Good to see it mentions autoconf, as such tests were my immediate > concern upon reading the intro. > > I presume the same problem will exist in other build systems that > probe for features, both well known ones like cmake/meson/etc, > but also home grown ones that are package specific (/me glares > at QEMU's 'configure' that merely pretends to look like it is > from autoconf, but is actually just a hand written shell script). > > > == Dependencies == > > To avoid regressing the porting effort, GCC as the system compiler > > needs to reject obsolete constructs by default. This is expected for > > GCC 14, to be released as part of Fedora 40 in Spring 2024. > > So this change is talking about a new GCC landing in Fedora 40. > > To avoid massive disruption to Fedora though, we need to be doing > work waaaaay earlier than the Fedora 40 dev cycle though. > > Identifying all the places where autoconf tests quietly change > their result, and silently toggle on/off alternative code paths > is going to be a big job on its own. > > Once identified there's the even more work to figure out the right > changes needed. I don't know how many packages rely on autoconf, > but the idea of carrying patches in Fedora and re-running autotools > to re-create configure, isn't that appealing on a large scale. > > Obviously the preferred solution is to be able to report the problems > upstream, and get the fixes included in the next upstream release > and then rebase in Fedora. Even better is if a major information > campaign brings this change directly to the attention of upstreams > communities, bypassing the distros where there is an active upstream. > > I'd be concerned about the timeframe for getting through this dance > for a non-negligible number of packages. > > > IOW, this change is talking about something in Fedora 40, but it > feels like the vast majority of work needs to take place in Fedora > 38 and Fedora 39. Fedora 40 neeeds to be nothing more than a "flip > the switch" scenario, otherwise history suggests the change is likely > to end up getting punted to Fedora 41/42. > > I feel that this need to start on the prep work in F38/F39 is not > very obvious from the F40 change proposal text. > > So shouldn't we have explicit distinct 'Fedora 38/39' change proposal(s) > to describe the prep work that needs to be done across packages in these > two releases as a matter of urgency, in order to make it possible to the > F40 change to actually happen ? > > > Concretely, as an upstream maintainer, what should they do to test > the behaviour of their code ? Is there more to it than just > setting CFLAGS="-std=gnu99", if they want to validate this in their > upstream CI ahead of GCC 14 arriving ? > Why C99? Why not C18 instead? If we're going to go through this effort, we should ramp up like we did for C++ and bump all the way up to the latest published standard. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
