* Zbigniew Jędrzejewski-Szmek:
On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
> == 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
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
(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
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
> 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.