c-std-porting.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Guillem Jover <guillem@debian.org>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: Florian Weimer <fweimer@redhat.com>,
	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: Wed, 19 Apr 2023 01:17:55 +0200	[thread overview]
Message-ID: <ZD8lI0ZL7wYYo8Pb@thunder.hadrons.org> (raw)
In-Reply-To: <20230418225420.qoedd6vam4pkobin@illithid>


On Tue, 2023-04-18 at 17:54:20 -0500, G. Branden Robinson wrote:
> 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.

> > 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.

At the time I got aware of this effort, I implemented a dpkg-buildflags
feature (qa=+c99) to enable most of these flags (see [F]), but didn't
mention it because it was not clear whether this was a desired
direction and the current implementation seemed slightly restrictive,
also due to the freeze.

But perhaps switching more gradually does indeed work better, at least
in the Debian context. I think the feature name is not great, because it
is not very descriptive and precisely because once used it could not be
currently extended, and that ties with work I've been doing to version
feature flags (but I guess this one could always be introduced and be
considered v0 or similar, probably with a better name(?)).


[F] https://git.hadrons.org/git/debian/dpkg/dpkg.git/commit/?h=next/modern-c&id=3316845bf415436299d61501db655fd2c1813436

  reply	other threads:[~2023-04-18 23:32 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
2023-04-18 23:17   ` Guillem Jover [this message]
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=ZD8lI0ZL7wYYo8Pb@thunder.hadrons.org \
    --to=guillem@debian.org \
    --cc=c-std-porting@lists.linux.dev \
    --cc=debian-devel@lists.debian.org \
    --cc=debian-gcc@lists.debian.org \
    --cc=fweimer@redhat.com \
    --cc=g.branden.robinson@gmail.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).