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 ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
