F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/PortingToModernC.

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== 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.

== Owner ==
* Name: [[User:fweimer| Florian Weimer]]
* Email: [mailto:[e-mail]| fweimer(a)redhat.com]


== 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-declarati...
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.

GCC 14 may also make other changes by default, as described below.
These changes will also require extensive testing, and some adoption
of configure checks.

==== Removal of old-style function definitions ====

An old style function definition looks like this:
<pre>
int
sum (a, b)
  char *a;
  int b;
{
  return atoi (a) + b;
}
</pre>
It is equivalent to this definition with a prototype:
<pre>
int
sum (char *a, int b)
{
  return atoi (a) + b;
}
</pre>
This legacy feature is very close to being incompatible with the C2X
standard, which introduces unnamed function arguments. But due to a
quirk in GCC's implementation, it should be possible to support both
at the same time.

==== New keywords <code>bool</code>, <code>true</code>,
<code>false</code> ====

Packages which supply their own definitions instead of including
`<stdbool.h>` (which remains available) might fail to build.

==== Change of meaning of <code>()</code> in function declarators ====

In earlier C versions, a declaration `int function()` declares
`function` as accepting an unspecified number of arguments of unknown
type. This means that both `function(1)` and `function("one")`
compile, even though they might not work correctly. In a future C
standard, `int function()` will mean that `function` does not accept
any parameters (like in C++, or as if written as `int function(void)`
in current C). Calls that specify parameters will therefore result in
compilation errors.

We believe that this change is ABI-compatible, even on ppc64le (with
its parameter save area), although it comes very close to an implicit
ABI break.

==== Rejecting implicit conversions between integers and pointers as errors ====

Currently, GCC does not treat conversion between integers at pointers
as errors, so this compiles:

<pre>
int ptr = "string";
</pre>

However, this is very unlikely to work on 64-bit architectures (it may
work by accident without PIE/PIC).

== Feedback ==

The transition plan has been discussed at various GNU Tools Cauldrons.
Feedback has been generally positive, except a general worry about the
work required.

Without a deliberate porting effort, a lot of breakage occurs,
[https://lists.fedoraproject.org/archives/list/[e-mail].o...
seen in 2016 in Fedora with an uncoordinated change], and more
recently
[https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werro...
an uncoordinated Clang update].

== Benefit to Fedora ==
Programmers will no longer waste time tracking down things that look
eerily like compiler or ABI bugs because in several cases, builds will
fail with a clear error message, instead of producing a warning that
is easily missed. Potential blockers to adoption of further C language
changes are removed.

== Scope ==
* Proposal owners: Update rawhide over time to be compatible with
strict C99 compilers.

* Other developers: Help out with non-obvious porting issues, and with
upstreaming patches in case active upstreams cannot be easily
identified. Tolerate early backports of upstream-submitted fixes in
Fedora dist-git.

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]

* Policies and guidelines: Fedora compiler policy will likely change
due to the adoption of GCC 14 in Fedora 40.

* Trademark approval: N/A (not needed for this Change)

* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
The change is expected to be transparent to those users who do not use
C compilers. No features are supposed to be added or removed as a
result. In fact, most of the porting effort focuses on avoiding
configuration changes.

== How To Test ==
General regression testing is sufficient.

== User Experience ==
User experience does not change.

== 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.
* Blocks release? No if GCC doesn't switch. If GCC switches, we have
to complete the port.


== 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.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis