Modern C porting

From Gentoo Wiki
Jump to:navigation Jump to:search

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:
    • -Werror=implicit-function-declaration
    • -Werror=implicit-int
    • -Werror=int-conversion (this is in Clang 15, actually)
    • -Werror=incompatible-function-pointer-types (GCC does not have a specific equivalent error, use -Werror=incompatible-pointer-types 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 -Wdeprecated-non-prototype for this
    • GCC does not have a targetted warning (yet?) but does have -Wstrict-prototypes (Clang has this too)

Why does it matter?

  • Lots of packages fail to build with these settings.
  • Sometimes packages build successfully but their ./configure scripts have misdetected features or otherwise made the wrong conclusion about the system because they expect a test to succeed when it now fails.



Where can I find a list of Gentoo bugs to hack on?

See bug #870412 and the list here.

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

How do I reproduce these bugs?

In general:

  1. Use Clang 16 and set CC=clang-16, or
  2. Use Clang 15 and set CC=clang-15 and =sys-devel/clang-common-15* stricter in /etc/portage/package.use/clang, or
  3. Use GCC and set -Werror=implicit-function-declaration -Werror=implicit-int -Werror=int-conversion -Werror=incompatible-pointer-types

configure or build system bugs

Developers may need to follow the above to setup their environment, run ./configure, then:

  • grep config.log, or
  • inspect ./configure, or
  • check other build system-generated files if the problem does not appear in build.log.

A /etc/portage/bashrc hook is available to save logs in /var/tmp/clang 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 /var/tmp/clang.

How do I install Clang 16?

Remember that it's fine to use Clang 15 or GCC with specific settings described above, so there's no specific need to use Clang 16.

Clang 16 is not yet released, so installation requires allowing the snapshots packaged in Gentoo to be installed:

FILE /etc/portage/package.accept_keywords
# Caveat emptor!
=dev-libs/libclc-16.0.0_pre* **
=dev-ml/llvm-ocaml-16.0.0_pre* **
=dev-python/clang-python-16.0.0_pre* **
=dev-python/lit-16.0.0_pre* **
=dev-util/lldb-16.0.0_pre* **
=sys-devel/clang-16.0.0_pre* **
=sys-devel/clang-common-16.0.0_pre* **
=sys-devel/clang-runtime-16.0.0_pre* **
=sys-devel/clang-toolchain-symlinks-16* **
=sys-devel/lld-16.0.0_pre* **
=sys-devel/lld-toolchain-symlinks-16* **
=sys-devel/llvm-16.0.0_pre* **
=sys-devel/llvm-common-16.0.0_pre* **
=sys-devel/llvmgold-16 **
=sys-devel/llvm-toolchain-symlinks-16* **
=sys-libs/compiler-rt-16.0.0_pre* **
=sys-libs/compiler-rt-sanitizers-16.0.0_pre* **
=sys-libs/libcxx-16.0.0_pre* **
=sys-libs/libcxxabi-16.0.0_pre* **
=sys-libs/libomp-16.0.0_pre* **
=sys-libs/llvm-libunwind-16.0.0_pre* **

Is this cosmetic?


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.

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.


  • Do not pass -Wno-error=...
  • GCC will usually helpfully emit a 'fixit' (an annotation to the warning/error with the missing header).
  • Add the relevant #include - 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


  • Do not pass -Wno-error=...
  • grep the codebase for uses of the function to determine the correct return type.
  • Do not assume it is supposed to be an int.


  • 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 -Wno-error=incompatible-function-pointer-types, 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).


  • 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 -std=gnu89 instead in CFLAGS in the ebuild if you don't fix them.


  • This is future proofing and can help with C23 onwards but is not strictly required right now.
  • Add -std=gnu89 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.

Tips & Tricks

Fixing K&R C declarations

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

 REmatch(pattern, start, end)
 char *pattern;
 int start,end;

needs to be reworked into this:

 REmatch(char *pattern, int start, int end)

This is not a very hard task, but it becomes exhausting when doing this for a larger project.

dev-util/cproto can automate this. For a given file, myCfile, cproto will convert (and return the prototypes of all functions it can find) with

user $cproto -a myCfile.c

Or for all the .c-files in a project:

user $find ./ -name "*.c*" | xargs cproto -a


See also