Modernizing Fedora's C code

It is not often that you see a Fedora change proposal for a version of the distribution that will not be available for 18 months or so, but that is exactly what was recently posted to the mailing list. The change targets the C source code in the myriad of packages that the distribution ships; it would fix code that uses some ancient compatibility features that were removed by the C99 standard but are still supported by GCC. As might be guessed from the long runway proposed, there is quite a bit of work to do to get there.

As usual with Fedora change proposals, this one was posted to the Fedora devel mailing list on behalf of its owner, Florian Weimer, by Fedora program manager Ben Cotton; it is also available in an updated form on the Fedora wiki. At the moment, Fedora 37 is imminent, but the proposal targets Fedora 40, which is currently slated for the northern-hemisphere Spring of 2024. The goal, as described by the title is "Porting Fedora to Modern C".

Old C

There are several C features that were removed from the language in the C99 standard, but are still accepted by default in GCC, so use of them exists in the extensive code base that makes up Fedora. The idea would be to start working on cleaning those up, hopefully in collaboration with other distributions, and getting those changes into the upstream projects. There are six different constructs that are targeted, but the most important is removing implicit function declarations:

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.

On 64-bit systems, implicitly returning a 32-bit int can result in a truncated pointer as was described in the linked blog post. Similarly, functions returning _Bool that are called after an implicit int declaration may have their return values misinterpreted because they do not modify all 32-bits of the return register.

Another problem identified is that, before C99, the following code would implicitly define two int variables since the type is not specified:

    static i = 1.0;
    auto j = 2.0;

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.

As noted in a message on the LLVM forum site, the Autconf scripts that are included with a project may rely on the implicit declarations and any compiler warnings or errors may get lost because of the way Autoconf is run. Tools are being developed to help find the problem code without upsetting the Autoconf apple cart. Collaboration with other distributions should also help in that process, the proposal said.

The other changes would fix some crufty constructs. The bool, true, and false keywords would be enforced; code that defines its own versions of those symbols would need to change. In addition, GCC does not treat the assignment of pointers to int variables as an error, which needs to be fixed. Old-style function definitions, such as:

    int sum(a, b)
        char *a;
        int b;
    { ...

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.

The benefits for Fedora are twofold, according to the proposal. Bugs that are sometimes hard to track down and "look eerily like compiler or ABI bugs" will be avoided because warnings that might be easily overlooked would become errors. In addition, it is believed that some of these legacy features are holding back progress in GCC. The proposal is looking forward to the release of GCC 14, which is expected to be included in Fedora 40. There is a belief that GCC 14 will disable support for those features by default, but even if that does not happen, Fedora 40 would change its defaults so that regressions are not introduced afterward.

Questions

Daniel P. Berrangé noted that Autoconf difficulties immediately sprang to mind when he saw the proposal. He pointed out that other build systems that probe for features by compiling up test programs of various sorts may also be affected. Weimer said that he had already found a problem of that sort in the Python setuptools. It generates test programs to determine whether certain functions are present in the environment, but those programs rely on implicit int, so they may fail with a strict compiler, but not because the function of interest is missing.

Berrangé had also asked about how developers could test their code to see if it has any of these problems; it is not simply setting -std=gnu99 since that will still allow the old constructs (for now at least). Weimer spelled out the list of flags needed ("It's -Werror=implicit-int -Werror=implicit-function-declaration. Best to throw in -Werror=int-conversion -Werror=strict-prototypes -Werror=old-style-definition."); he also updated the proposal on the wiki so that each of the flags was tied to the obsolete feature it would catch.

Alexander Sosedkin wondered why the porting effort couldn't be distributed and proceed at a more leisurely pace. To start, every package could be marked as not supporting the change and the defaults for GCC could be switched for all packages that do support it; nothing would change at that point, but packages could slowly make the changes needed and toggle their flag. Though Weimer wishes it could be done that way, he really does not think that a distributed porting effort is feasible; "we'd have to teach many more people about C arcana and autoconf corner cases. I don't think that's a good learning investment to be honest."

Vit Ondruch asked about the status of the effort and the number of packages that will be affected by it. Weimer said that he was still figuring that out, but his preliminary run found about 10% of the Fedora packages were affected, which he believes is an overestimate. That certainly seems like a daunting number, though, since Fedora has more 60,000 packages in its repository, the bulk of which are written in C.

There were no major complaints heard about the change in the thread. Gentoo is working on a similar set of changes for Clang 16, which already rejects the legacy C constructs; that should cut the work roughly in half, with luck. More distributions joining the party could reduce it further still. The Fedora Engineering Steering Committee (FESCo) will need to consider the proposal to decide whether the distribution should pursue it; as yet, the proposal is still in the discussion phase. It's a lot of work—thankless work, in truth—but would help modernize the code for lots of projects. Fedora would obviously benefit from that modernization as well.