[prev in list] [next in list] [prev in thread] [next in thread] 

List:       autoconf
Subject:    Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?
From:       "David A. Wheeler" <dwheeler () dwheeler ! com>
Date:       2023-12-11 15:55:55
Message-ID: C1745160-BC1F-469F-977A-92D4F758EB80 () dwheeler ! com
[Download RAW message or body]

All:

Will the latest version of autoconf work by default when the compiler has these \
                options enabled?:
-Werror=implicit-int
-Werror=implicit-function-declaration

If not, can that be fixed at least in the most common cases (e.g., by declaring \
exit() so it's no longer an implicit function nor using an implicit int)?

Below are details.

Sorry for the late notice/question. I realize an autoconf update is about to be \
released. However, I *just* became aware of this issue. This particularly hints \
clang, because a late change in Clang appears to cause implicit function declarations \
to be errors by default. Details/context below.

--- David A. Wheeler


=== Details ===

The Open Source Security Foundation (OpenSSF) has developed
"Compiler Options Hardening Guide for C and C++"
<https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++>
 which gives recommended compiler flags to detect/counter bugs (especially \
vulnerabilities). The guide is in active development. We want to strongly encourage \
using various options to detect bugs as soon as possible (ideally at compile time \
when that's practical).

A proposed change here: \
<https://github.com/ossf/wg-best-practices-os-developers/issues/339> suggests \
implementing the Fedora project's "Porting to Modern C" \
<https://fedoraproject.org/wiki/Changes/PortingToModernC> where "modern" is C99 (~24 \
years old).

That Fedora document recommends turning on "-Werror=implicit-int", however, it notes \
that:
> ... 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. Various tools for this porting activity are being developed to \
> support this proposal. Cross-distribution collaboration will help as well, sharing \
> patches and insights.

*Another* proposed change to the OpenSSF guide
<https://github.com/ossf/wg-best-practices-os-developers/issues/342>
*also* recommends adding "-Werror=implicit-function-declaration", in this case \
because it's listed in "Florian Weimer's 2018 article "Recommended compiler and \
linker flags for GCC" \
<https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc>.

However, there are discussions that suggest that autoconf struggles when \
-Werror=implicit-function-declaration is enabled (e.g., by clang default): \
https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213/5

> "We've noticed some worrying problems resulting from the late change in Clang that \
> causes implicit function declarations to be errors by default 105. It seems that \
> many configure (e.g. autoconf) scripts were silently relying on the old behavior, \
> and the change is causing them to misfire."

It'd be great if autoconf "just worked" when enabling "modern C" options, especially
"-Werror=implicit-int" and "-Werror=implicit-function-declaration".


[prev in list] [next in list] [prev in thread] [next in thread]