* Zbigniew Jędrzejewski-Szmek: > On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/PortingToModernC. > > Line-by-line review: > >> == Summary == >> Back in 1999, a new revision of the C standard removed several >> backwards compatibility features. However, GCC still accepts these >> obsolete constructs by default. Support for these constructs is >> confusing to programmers and potentially affect GCC's ability to >> implement features from future C standards. > > Miro already hinted at this, but to be explicit: this Summary does not > actually give the information that should be in a summary. It provides > some history that maybe belongs in the Detailed Description part. > > This part should say something like """gcc compiler will start rejecting some > long-deprecated constructs in C and implement some other backwards-incompatible > changes. Packages and build systems for user programs must be adjusted to > be compatible, or opt-out of the change by specifying …. > > The following constructs are now disallowed by default: implicit > function declarations, implicit int type declarations, old-style K&R > function parameter declarations, and in addition functions declared > with no parameters will now accept no instead of any parameters, and > new 'bool', 'true', 'false' keywords have been introduced.""" > > (I assume this is about gcc, not clang. But please be explicit.) I don't know the exact set of changes GCC 14 will bring at this point. I'm going to tweak the text to say that this is done to be compatible with expected future compiler and languages changes. Clang upstream will likely proceed on a much more aggressive timeline. The LLVM maintainers are discussing how Fedora should deal with that. >> == How To Test == > > As discussed by others, this needs to explain how to opt-in for early > testing, and also how to opt-out in packages, how to opt-out as a user > (if the default touches users), etc. The challenge with that is that I've been told not to do this work in Fedora proper by release engineering, and a request for a long-living side tag with a suitable compiler has not been approved: Long-term side tag for toolchain experiment <https://pagure.io/releng/issue/10392> More recently, I was explicitly told not to keep the compiler changes on a branch in Fedora dist-git. It is not really possible to get realistic testing through compiler flag injection because crufty old code that is problematic for these changes often does not inject flags properly. Certain likely changes cannot be modeled through -Werror= options (but can be patched into GCC). Some build systems explicitly filter out -Werror= options during the configure stage (generally a good idea, but not helpful here). So I'm a bit at a loss what to do here. Maybe releng can reconsider their approach. >> User experience does not change. > > "The new default for C standard is -c99. Users who want to use > an older standard need to specify something like -c89." (???) For GCC 14, it's likely C23, C24 or even C25 (the calendar year for ISO standards is very unpredictable). GCC and Clang defaults are already at C17/C18, it's just that they still accept obsolete C89 or K&R constructs that have been removed from C99. It's not clear at this point if -std=c99 would enable, say, implicit ints in GCC 14 because they aren't part of C99. Probably not. >> == 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. >> >> == Contingency Plan == >> * Contingency mechanism: Upstream GCC will probably accept obsolete >> constructs longer in case distributions like Fedora cannot port to >> modern C in time. > > Hmm, this sounds ominous, like if GCC might stop accepting old C syntax > altogether. Isn't this just a question of specifying the right standard > in compilation options? GCC will not go the Clang route and implement what are essentially language changes through -Werror= options, it will be controlled primarily via -std=, and maybe there will be separate -f options to enable certain things. Some combinations may not be available at all (e.g., C2X with implicit ints). Support for some extensions may be gone completely (like support for writable string constants was removed from the compiler a while back). >> == Documentation == >> This section will be updated once more documentation of the porting >> effort will become available. >> >> == Release Notes == >> Probably not needed because no user visible impact is intended. > > It's not clear from the description: what about users who compile programs? As discussed before, that falls under general porting for toolchain upgrades. There will separate toolchain Change proposals for Fedora 38 and Fedora 40 at least. Thanks, Florian _______________________________________________ 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
