Modern C porting

Set of notes for Modern C porting.

This has two phases:
 * 1) Preparation for Clang 16 and GCC 14 (now)
 * 2) Preparation for C23 becoming default (in the future)

TODO: mention GNU_SOURCE and other FTMs

What changed?

 * Clang 16 (to be released appx. March 2023) will make the following default errors:
 * (this is in Clang 15, actually)
 * (GCC does not have a specific equivalent error, use  instead when testing)
 * (this is in Clang 15, actually)
 * (GCC does not have a specific equivalent error, use  instead when testing)


 * GCC 14 (to be released appx. May 2024) is likely to do the same.

What will change in a few years?

 * C2x (likely C23) makes additional changes like removing certain deprecated prototypes. This is not the main priority for now.
 * Clang has  for this
 * GCC does not have a targeted warning yet but does have  (Clang has this too)

Why does it matter?

 * Lots of packages fail to build with these settings.


 * Sometimes packages build successfully but their scripts have misdetected features or otherwise made the wrong conclusion about the system because they expect a test to succeed when it now fails.

Examples

 * SDL thought no joystick support existed (https://github.com/libsdl-org/SDL/pull/6217)
 * stopped installing any extensions and would hang at runtime -
 * would install but cause compilation to loop forever -

Where can I find a list of Gentoo bugs to hack on?
See and the list here.

Additionally, for C23 preparedness (see above), see. This is lower priority for now.

How do I reproduce these bugs?
In general:
 * 1) Use Clang 16 and set , or
 * 2) Use Clang 15 and set   and   in, or
 * 3) Use GCC and set

configure or build system bugs
Developers may need to follow the above to setup their environment, run, then:
 * grep, or
 * inspect, or
 * check other build system-generated files if the problem does not appear in.

A hook is available to save logs in  to help capture issues from homebrew configure scripts which do not log. In order to use this without root rights with the ebuild command, make sure that users have writing privileges for.

How do I install Clang 16?
Clang 16 has been released, so simply:

Is this cosmetic?
No!

Implicit function declarations can affect code generation. They've been a long-standing cause of runtime failures like crashes. They are particularly a problem if the calling convention for an architecture is sufficiently "different", e.g. Apple's ARM64 ABI.

Even on amd64, it can cause problems: if a function returns a _Bool in reality but the prototype is missing, the compiler will assume int. On amd64, this causes messy corruption because there's no obligation for a _Bool to have filled the remaining bits correctly.

A new revision of the ebuild is required for fixing these bugs because of the possible runtime effects.

How do I fix these bugs?
All of these fixes require a new revision ("revbump") for the reasons described above. Also, developers want to know quickly if the fix is somehow insufficient, and a new revision helps to weed out any problems.

-Wimplicit-function-declaration

 * Do not pass
 * GCC will usually helpfully emit a 'fixit' (an annotation to the warning/error with the missing header).
 * Add the relevant  - determine this possibly by looking at man pages for the missing functions, or grepping in the codebase
 * Internal functions
 * grep the codebase for uses of the function to determine the correct return type.
 * Sometimes packages are just missing includes for their own internal functions
 * Sometimes adding a prototype into an internal header is needed

-Wimplicit-int

 * Do not pass
 * grep the codebase for uses of the function to determine the correct return type.
 * Do not assume it is supposed to be an int.

-Wincompatible-function-pointer-types

 * grep the codebase for uses of the function to determine the correct return type.
 * This can often be somewhat convoluted and may require filling in various prototypes both to head off possible C23 issues but also to make the compiler give better errors
 * Sometimes it's useful to temporarily put in the _wrong_ type just to get a better error, rather than _no_ type
 * These bugs are the hardest to solve and often require understanding the intent of the software's author. It's okay to feel stuck with these.
 * Many of these end up being last-rite candidates because they're abandoned upstream and have other code smells.
 * It's not always possible (or at least practical) to determine the correct types if the codebase is particularly old because they relied on ambiguity.
 * In some extreme cases, it may be okay to pass, but please avoid it.
 * If doing this, make sure there's an upstream report, or if upstream is gone, that there's truly no alternative to this software available (so we can last-rite).

-Wdeprecated-non-prototypes

 * It'd be swell if you fix these but you don't have to for Clang 16 / GCC 14. But they're easy to do usually.
 * Add  instead in CFLAGS in the ebuild if you don't fix them.

-Wstrict-prototypes

 * This is future proofing and can help with C23 onwards but is not strictly required right now.
 * Add  instead in CFLAGS in the ebuild if you don't fix them.

Do I have to send patches upstream?

 * If upstream still exists, yes, please do. We need other distributions to do the same as well. This is a huge task and we can't be needlessly duplicating work. It's also just part of being a good FOSS citizen, of course.
 * If upstream is completely gone, of course, you need not feel guilt.

Fixing K&R C declarations
Often errors are caused by old K&R style function definitions. So this:

needs to be reworked into this:

This is not a very hard task, but it becomes exhausting when doing this for a larger project. can automate this. For a given file,, will convert (and return the prototypes of all functions it can find) with Or for all the .c-files in a project:

Using Clang on a package-basis
Clang can be used only for specific packages by leveraging Portage's mechanism. Files similar to the following should be created.

Including a link to the relevant bug as a comment in the entry makes it easier to keep track of the context for that package.

Using Portage to find build system bugs
Portage (as of version 3.0.45.1) will scan the standard configure logs for configure-time implicit function declarations as part of a post-install QA check. Any results that found are given as a QA message as well as logged into in the package build tree in a script-friendly format.

If the message is a false positive (e.g. BSD-only functions), mark them as such in  in the ebuild.

If the message is from tests built in to autoconf (not from the package's own configure.ac or m4 macros), then try.

Resources

 * c-std-porting list
 * Modernizing Fedora's C code
 * Clang 16 is coming - and it'll break your packages!
 * Clang 16 / modern C porting in Gentoo -
 * C23 porting in Gentoo -
 * Porting to Modern C (Fedora)
 * Porting to Modern C (Fedora, Toolchain) (equivalent of this page)
 * Red Hat Bugzilla - Porting Fedora to Modern C
 * Red Hat Bugzilla - Tracker for porting Fedora to modern C
 * Red Hat Bugzilla - Porting Fedora to modern C: Bugs that need help
 * Red Hat Bugzilla - Porting Fedora to modern C: Bugs without (referenceable) upstream
 * Red Hat Bugzilla - Porting Fedora to modern C: exemptions
 * F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)
 * Configure script breakage with the new -Werror=implicit-function-declaration
 * Unresolved issues from the LLVM 15.x release
 * LPC 2021 - GNU Tools Track (Eliminating implicit function declarations)