Toolchain/PortingToModernC

Porting Fedora to Modern C

This page collects some technical details related to Changes/PortingToModernC.

Status

• Gathering data on implicit function declarations (e.g., exit (0) called without #include <stdlib.h>).
• Gathering data on implicit ints (e.g., const TWO = 2).
• Preparing infrastructure for fix verification for Fedora developers.

Discovering Packages Which Need Fixing

We build packages with instrumented gcc and redhat-rpm-config packages that fail the build if certain errors occur anywhere during the build. These forced failures are guaranteed to happen even if the build system ignores the exit status of a gcc command and continues regardless (for example, during configure checks). This is implemented by patching gcc in a special buildroot to log certain errors to a 1777 (sticky bit permission) directory. After the build, redhat-rpm-config checks if the directory is empty (or more precisely, only contains expected errors), and fails the build otherwise.

• rawhide gcc fork with instrumentation
• rawhide redhat-rpm-config fork with instrumentation

Special COPR repository with instrumented GCC

A COPR repository contains instrumented packages. Builds fail if they use any of the obsolete features currently under test. Presently these are:

• Implicit function declarations. Limitations:
  • Some functions are expected to be undefined (e.g., pledge does not exist on Linux). Calls to them result in implicit declarations, which is a false positive in this context. As a result, in the redhat-rpm-config package, there is an exception list in the reporting code.
• Implicit int (in variable declarations, and missing function return types). Limitations:
  • Unsupported specifiers like __declspec(thread) can be parsed as old-style function definitions with a parameter implicitly typed as int, leading to a false positive implicit int. There is currently no remedy for this, but we hope to fix this in the instrumented GCC at this point. (Roughly speaking, __declspec is the Microsoft compiler equivalent of __attribute__.)

The instrumentation in redhat-rpm-config checks after the various stages (e.g., %build and %prep) if gcc has logged anything. If yes, it fails the build with a message like this one:

*** GCC errors begin ***
conftest.c:55: type defaults to int
conftest.c:37: implicit function declaration: exit
conftest.c:83: defaulting to int
conftest.c:84: implicit function declaration: offsetof
conftest.c:293: defaulting to int
conftest.c:71: type defaults to int
*** GCC errors end ***

As a convenience, a dump of config.log files is included in the build log before these errors are listed.

From time to time, error checking will break if newer gcc or redhat-rpm-config builds arrive in rawhide.

The following mock configuration can be used for local builds.

config_opts['target_arch'] = 'x86_64'
config_opts['legal_host_arches'] = ('x86_64',)

include('templates/fedora-rawhide.tpl')

config_opts['root'] = 'fedora-rawhide-modernc'

config_opts['dnf.conf'] += """

[copr-fweimer-modernc]
name=COPR with instrumented GCC for modern C porting
baseurl=https://download.copr.fedorainfracloud.org/results/fweimer/modernc-1/fedora-rawhide-$basearch/
type=rpm-md
skip_if_unavailable=False
gpgcheck=1
gpgkey=https://download.copr.fedorainfracloud.org/results/fweimer/modernc-1/pubkey.gpg
repo_gpgcheck=0
enabled=1
enabled_metadata=1
"""

Fedora Package Updates

All identified issues need to be fixed in rawhide eventually. If a package cannot be ported, a bug needs to be filed in Bugzilla blocking PortingToModernCExemptions to record this, and the package still needs to build in an early C language mode (probably C89 or C99).

If an upstream fix becomes available, it may make sense to backport it before a package rebase, so that the package no longer shows up as needed porting worj.

Compatibility packages and other legacy packages need to be fixed as well.

Documenting Changes

• Fedora dist-git commit message should refer Changes/PortingToModernC and Toolchain/PortingToModernC (this page).
• Fedora updates should be captured in the fedora-modernc tracking repository. Please send MRs there if you fix something.
• Changes that merely included what would come in through a future rebase do not need a bug in Bugzilla or filing an issue with upstream. This includes backports from upstream, or patches which merely change generated files when re-generation using the current tool version would also fix the issues. (The latter is common with old configure scripts.)
• Patch files added as part of this change must include a URL for an upstream commit or for an upstream patch submission.
• A bug needs to be filed in Bugzilla if there is no way to report the issue upstream, blocking PortingToModernCNoUpstream.
• If a package cannot be ported, a bug needs to be filed blocking PortingToModernCExemptions.

Cross-Distribution Collaboration

A mailing list has been set up to exchange issues and observations of wider interest: c-std-porting@lists.linux.dev (archive)

Further resources will follow as needed.

Fedora Change Tracking

Changes to Fedora packages should be captured in the fedora-modernc tracking repository.

Not every build issue will have a bug in Bugzilla. But if there is no upstream with a mailing list or issue tracker to submit fixes to, it makes sense to create a bug in Bugzilla, especially for cross-distribution collaboration.

Currently, these trackers exist:

• PortingToModernC Umbrella tracker for the tracker bugs below.
• PortingToModernCExemptions Bugs which document that certain packages could not be switched to C99 or later language standards. Typically these packages keep building with -std=gnu89.
• PortingToModernCHelpNeeded Bugs where help from the package maintainer is needed to address the issue(s).
• PortingToModernCNoUpstream Bugs to provide a reference where there is either no upstream, or the current upstream lacks a public bug tracker or version control repository

Contributing To The Porting Effort

If you want to contribute to this effort, you should subscribe to the c-std-porting list mentioned above. If you create a Red Hat Bugzilla account, log in, and visit the Bugzilla tracker bugs linked above, a Add me to CC list check mark will appear on the bug pages. If you check that and click the Save Changes button, you will be notified of future bug changes, including bug dependency changes that indicate new issues. You can also subscribe to individual bugs that interest you.

At this point, it is too early to tell what level of knowledge and open-source experience is typically needed to successfully contribute to this project.