From: Omar Sandoval <osandov@osandov.com>
To: Qu WenRuo <wqu@suse.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 0/4] btrfs-progs: Compiling warning fixes for devel branch
Date: Tue, 19 Nov 2019 12:38:52 -0800 [thread overview]
Message-ID: <20191119203852.GA260588@vader> (raw)
In-Reply-To: <a4509699-27c0-d70a-fe6f-033e20d8219e@suse.com>
On Mon, Nov 18, 2019 at 11:47:41PM +0000, Qu WenRuo wrote:
>
>
> On 2019/11/19 上午2:27, Omar Sandoval wrote:
> > On Mon, Nov 18, 2019 at 02:30:48PM +0800, Qu Wenruo wrote:
> >> We have several compiling errors, in devel branch.
> >> One looks like a false alert from compiler, the first patch will
> >> workaround it.
> >>
> >> 3 warning from libbtrfsutils are due to python3.8 changes.
> >> Handle it properly by using designated initialization, which also saves
> >> us quite some lines.
> >>
> >> Qu Wenruo (4):
> >> btrfs-progs: check/lowmem: Fix a false alert on uninitialized value
> >> btrfs-progs: libbtrfsutil: Convert to designated initialization for
> >> BtrfsUtilError_type
> >> btrfs-progs: libbtrfsutil: Convert to designated initialization for
> >> QgroupInherit_type
> >> btrfs-progs: libbtrfsutil: Convert to designated initialization for
> >> SubvolumeIterator_type
> >>
> >> check/mode-common.c | 2 +-
> >> libbtrfsutil/python/error.c | 49 ++++++++-------------------------
> >> libbtrfsutil/python/qgroup.c | 43 ++++++-----------------------
> >> libbtrfsutil/python/subvolume.c | 44 ++++++-----------------------
> >> 4 files changed, 30 insertions(+), 108 deletions(-)
> >
> > Thanks for fixing the libbtrfsutil parts. For some reason, the
> > convention for Python C extensions is to not use designated
> > initializers, but after this breakage it's definitely safer to use them.
> >
> > I guess Dave already merged these, but FWIW,
> >
> > Reviewed-by: Omar Sandoval <osandov@fb.com>
> >
> A small question inspired by this bug, but not specific to btrfs.
>
> Does this mean each big python upgrade makes all c-binding binary
> incompatible? Or this is just a hiccup for this python3.8 release?
>
> If it's the former case, that doesn't look correct to me...
In general, each major Python version may change the C extension ABI,
which is why the Python version is encoded in the file name:
/usr/lib/python3.8/site-packages/btrfsutil.cpython-38-x86_64-linux-gnu.so
Usually they maintain source-level compatibility, but it appears that
CPython itself uses 0 for its unused initializers rather than NULL, so
they probably just missed this.
prev parent reply other threads:[~2019-11-19 20:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-18 6:30 [PATCH 0/4] btrfs-progs: Compiling warning fixes for devel branch Qu Wenruo
2019-11-18 6:30 ` [PATCH 1/4] btrfs-progs: check/lowmem: Fix a false alert on uninitialized value Qu Wenruo
2019-11-18 6:30 ` [PATCH 2/4] btrfs-progs: libbtrfsutil: Convert to designated initialization for BtrfsUtilError_type Qu Wenruo
2019-11-18 6:30 ` [PATCH 3/4] btrfs-progs: libbtrfsutil: Convert to designated initialization for QgroupInherit_type Qu Wenruo
2019-11-18 6:30 ` [PATCH 4/4] btrfs-progs: libbtrfsutil: Convert to designated initialization for SubvolumeIterator_type Qu Wenruo
2019-11-18 8:23 ` [PATCH 0/4] btrfs-progs: Compiling warning fixes for devel branch Nikolay Borisov
2019-11-18 18:10 ` David Sterba
2019-11-18 18:27 ` Omar Sandoval
2019-11-18 23:47 ` Qu WenRuo
2019-11-19 20:38 ` Omar Sandoval [this message]
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=20191119203852.GA260588@vader \
--to=osandov@osandov.com \
--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 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).