Update on the Modern C initiative

[Florian Weimer]

This message is realted to:

  <https://fedoraproject.org/wiki/Changes/PortingToModernC>
  <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>

The final patches for GCC 14 are currently under upstream review and
should land very soon.  Earlier, I had received feedback that the larger
community desires just one transition, so we end up with the following
warnings which turn into errors by default:

  -Wimplicit-function-declaration
  -Wimplicit-int
  -Wint-conversion
  -Wreturn-mismatch (new, previously part of -Wreturn-types)
  -Wdeclaration-missing-parameter-type (new, previously unnamed)
  -Wincompatible-pointer-types

Only the first two were covered in the initial Fedora conversion work.

I've done another round of test builds with an instrumented GCC for all
errors, and the numbers of problematic packages I have today are:

                                          autoconf
                                      all     only
  implicit-function-declaration        53       21
  implicit-int                          2        0
  int-conversion                       99       33
  return-mismatch                      13        2
  declaration-missing-parameter-type    0        0
  incompatible-pointer-types          374       50
                                      487       89

(I've updated the change page to describe those diagnostics briefly.)

The numbers don't add up because one package can have multiple issues.
Some of the reported issues are false positives, although the GCC
instrumentation is a bit better than it used to be.

The autoconf column covers packages which are particularly at risk for
silent miscompilation because of incorrect detection of build system
features.  This is based on file name heuristics and includes more than
just autoconf proper.

As you can see, the incompatible-pointer-types issues are a bit of a
problem.  We fixed over 800 packages during the first round, and now it
looks like we are only two thirds done.

It is unlikely that I will be able to work on all these issues
myself or with help from the people around me.  I just suggested to GCC
upstream that we may have to reconsider including this change in the GCC
14 release.

Consequently, my priorities are as follows:

* Try to resolve the autoconf issues in packages, to reduce the risk of
  silent miscompilation.

* Integrate a backport of the GCC 14 changes into the rawhide GCC 13
  version (rawhide only, not Fedora 39 or 38).  This will allow us
  to isolate these issues from GCC 14 issues that typically occur
  during the upcoming mass rebuild.

* Produce the final redhat-rpm-config integration, using -fpermissive
  for _build_type_safety_c 0, and -Wno-error= options for the higher
  type safety levels.  This obviously depends on -fpermissive and and
  the new warning names becoming available in rawhide, which is another
  reason for the GCC 13 backport.

* Come up with a way to resolve the Vala situation, likely by embedded
  “#pragma GCC diagnostic” in the generated C source files.  Vala is
  currently not able to generate type-safe C, and is unlikely that this
  going to change soon.  (The numbers above do not include packages
  which have failures in Vala code only.)  In some cases, there is
  nothing that can be done about this on the Vala source code side.  Not
  all of these type errors are harmless, of course, but I don't see a
  way to deal with this except by telling GCC to be less picky.

I'm attaching package maintainer lists, generated using the
find-package-maintainers script from fthe
<https://pagure.io/fedora-misc-package-utilities/> repository, for both
the full package set, and the autoconf-impacted package set.

Build logs with results from the instrumentation are available here;

  <https://gitlab.com/fweimer-rh/fedora-modernc-logs/>

We delete logs from that repository as packages get fixed.

Again, some of these are false positives.  The second link at the start
has instructions for a COPR repository if you want to verify things
locally (sadly the Koji build target is currently not in working order).

Thanks,
Florian