c-std-porting.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: debian-devel@lists.debian.org, debian-gcc@lists.debian.org,
Subject: Re: RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.)
Date: Tue, 18 Apr 2023 17:54:20 -0500	[thread overview]
Message-ID: <20230418225420.qoedd6vam4pkobin@illithid> (raw)
In-Reply-To: <87y1mpe11q.fsf@oldenburg.str.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 6099 bytes --]

[I am not subscribed to debian-gcc or c-std-porting]

Hi Florian,

At 2023-04-18T16:07:45+0200, Florian Weimer wrote:
> TL;DR: I want to propose a GCC 14 change which will impact
> distributions, so I'd like to gather some feedback from Debian.
> Clang has disabled support for a few historic C features by default
> over the last few releases.  This mirrors a process that Apple has
> begun in Xcode even earlier (perhaps motivated in part by their
> AArch64 Darwin ABI, which is pretty much incompatible with some of the
> C89-only features).
> These changes bring real benefits to C programmers because errors are
> much harder to miss during the build than warnings.  In many cases,
> the compiler is not able to generate correct code when such issues are
> present, and programmers who look at the generated machine code
> suspect a compiler bug.  And all this happens because they missed a
> warning.  So we want this change for GCC, too.
> Specifically, I'm investigating the following changes:
> * -Werror=implicit-function-declaration: Functions can no longer be
>    called without be declaring first.  Fixing this may need additional
>    prototypes in package header files, or inclusion of additional
>    header files (both package-specific and system headers).
> * -Werror=implict-int: int types can no longer be omitted in old-style
>    function definitions, function return types, or variable
>    declarations or definitions.  Fixing that involves adding the int
>    type (or the correct type if it is not actually int).  If there is
>    already a matching declaration in scope that has a different type,
>    that needs to be resolved somehow, too.
> I want to propose at least the first two for GCC 14.
> The exact mechanism how the default is changed may not be -Werror=,
> perhaps something along the lines of -fpermissive for C++.  The C89
> modes (-std=gnu89 etc.) will likely still enable all these features
> (even if they are not part of C89).  As an opt-out mechanism,
> -std=gnu89 is insufficient because there are packages out there which
> use features which are C99-and-later-only in GCC (predominantly
> C99-style inlining, I believe) together with
> implicit-int/implicit-function-declaration.

Perhaps the thing to do here is have, <gulp>, yet another command-line
option for GCC.  The Ada language did something similar a couple of
decades ago to tighten up the language for hard real-time demands, with
what it called the "Ravenscar profile".[1]  That proved successful (as
successful as anything was in poor neglected Ada).

The term "profile" is perhaps unfortunate since it already has another
meaning in software performance measurement.  Maybe we could use the
term "contour", which isn't any longer, unlike "silhouette".  A
"contour" furthermore suggests boundaries, which would seem to be
apropos for what you're trying to do in two respects: (a) "ruling out"
certain coding practices that are accepted as standard, or at least
tolerated, otherwise; and (b) reducing the amount of undefined behavior
compiled code exhibits.

Whatever its name, some advantages to this approach are that
distributors could opt-in to such a thing, make it a clear matter of
policy, and more easily track adoption and progress.  You could also
version the contour much like the C standard itself.  So, for instance,
you introduce a contour called "clave23"[2] with the above features...

> * (tentative) -Werror=int-conversion: Conversion between pointer and
>   integer types without an explicit cast is now a compiler error.
>   Usually fixed by one of the two things above.  I do not have data
>   yet how many other cases remain after the initial issues are fixed,
>   but should have that in the coming weeks.  (Quite frankly, I'm
>   amazed that we created 64-bit ports without making this an error.)

So was I, 20 years ago when working on IA-64 ports...

> * (very tentative) -Werror=incompatible-pointer-types: GCC will no
>   longer automatically convert between pointer values of unrelated
>   pointer types (except when one of them is void * or its qualified
>   versions).  The fallout from this could be quite large, I do not
>   have data yet.  Clang does this for function pointer types only
>   (probably based on their ABI issues), but I'm not sure if it's a
>   reasonable distinction for our ABIs (the ppc64le cases I've seen had
>   explicit casts and no warnings).

And then perhaps adopt the above two for "clave26" in 2026 or so.

> * For -Wdiscarded-qualifies (e.g., using const pointers as non-const),
>   and -Wpointe-rsign (using char * as unsigned char *) I do not have
>   any plans.

With a versioned "profile" or "contour", you need not eat the elephant
all at once, and maintain ambitions that seem hopelessly distant today.

> I would appreciate some discussion on the Debian impact.  As Debian
> generally doesn't do mass rebuilds and we have upstreamed the fixes,
> maybe the impact is somewhat reduced?  Given that you'll get the fixes
> as part of the rebases.  Of course, other mass-changes might trigger
> rebuilds at a larger scale.  I guess it also depends on when you want
> to update to GCC 14.  The later, the more likely other packages have
> already imported the upstream fixes.  The alternative would be to
> apply the fixes in a proactive manner, like we are trying to in
> Fedora.

Debian has little fear of sweeping transitions, but it does like them to
be precisely defined in scope, and easily measured in adoption.  The
addition of a versioned contour flag to "DEB_BUILD_OPTIONS" or
similar[3] is straightforward to measure by scanning source packages.

I am sure my fellow developers can spot any problems my suggestions
might imply.


[1] https://www.adaic.org/resources/add_content/standards/05rat/html/Rat-5-4.html
[2] The name "clave" is not meant to be especially meaningful.
[3] https://www.debian.org/doc/debian-policy/ch-source.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-04-18 22:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18 14:07 RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.) Florian Weimer
2023-04-18 22:54 ` G. Branden Robinson [this message]
2023-04-18 23:17   ` Guillem Jover
2023-04-19 12:06   ` Florian Weimer
2023-04-19  0:25 ` Paul Wise
2023-04-19  1:14   ` Arsen Arsenović
2023-04-19  2:39 ` Oskari Pirhonen
2023-04-19  4:10   ` Sam James

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230418225420.qoedd6vam4pkobin@illithid \
    --to=g.branden.robinson@gmail.com \
    --cc=c-std-porting@lists.linux.dev \
    --cc=debian-devel@lists.debian.org \
    --cc=debian-gcc@lists.debian.org \
    --cc=fweimer@redhat.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).