From: Josef Bacik <josef@toxicpanda.com>
To: David Sterba <dsterba@suse.cz>
Cc: Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs-progs: enable -Wmissing-prototypes for debug builds
Date: Tue, 2 May 2023 10:25:33 -0400 [thread overview]
Message-ID: <20230502142533.GA1493492@perftesting> (raw)
In-Reply-To: <20230502133045.GD8111@suse.cz>
On Tue, May 02, 2023 at 03:30:45PM +0200, David Sterba wrote:
> On Tue, May 02, 2023 at 08:00:57PM +0800, Qu Wenruo wrote:
> >
> >
> > On 2023/5/2 19:41, David Sterba wrote:
> > > On Tue, May 02, 2023 at 09:29:30AM +0800, Qu Wenruo wrote:
> > >> During development I'm a little surpirsed we don't have
> > >> -Wmissing-prototypes enabled even for debug builds.
> > >
> > > The build supports W=levels like kernel and -Wmissing-prototypes is in
> > > level 1. In some cases we may want to add the warnings to be on by
> > > default for debugging builds though.
> >
> > I just did a quick search for the word "missing" of progs Makefile,
> > unforunately no hit, thus I doubt if it's even in debug level 1.
> >
> > And the missing prototypes warning is by default enabled for kernel.
>
> $ grep missing Makefile.extrawarn
> warning-1 += -Wmissing-declarations
> warning-1 += -Wmissing-format-attribute
> warning-1 += $(call cc-option, -Wmissing-prototypes)
> warning-1 += $(call cc-option, -Wmissing-include-dirs)
> warning-1 += $(call cc-disable-warning, missing-field-initializers)
> warning-2 += $(call cc-option, -Wmissing-field-initializers)
>
> > [...]
> > >>
> > >> +#include "sha.h"
> > >
> > > This does not seem necessary, include whole file just for one prototype.
> >
> > This is necessary as we would define a global function, without
> > including the header we got the missing prototype warning.
> >
> > All the other comments make sense and I would update the patchset.
> >
> >
> > The only other concern is, would this extra warning causing more hassles
> > for Josef to sync the kernel and progs code?
>
> I don't know yet but it is possible that it would. In that case the separate
> patch would make it easier to enable once all warnings are fixed, I can keep it
> at the top of the branch.
Do you want me to run these warnings through my series and re-send? That may be
faster than trying to merge everything together. Thanks,
Josef
next prev parent reply other threads:[~2023-05-02 14:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-02 1:29 [PATCH] btrfs-progs: enable -Wmissing-prototypes for debug builds Qu Wenruo
2023-05-02 9:30 ` Anand Jain
2023-05-02 11:41 ` David Sterba
2023-05-02 12:00 ` Qu Wenruo
2023-05-02 13:30 ` David Sterba
2023-05-02 14:25 ` Josef Bacik [this message]
2023-05-02 14:51 ` David Sterba
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230502142533.GA1493492@perftesting \
--to=josef@toxicpanda.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.