From: bugzilla-daemon@kernel.org
To: linux-xfs@vger.kernel.org
Subject: [Bug 219203] xfsprogs-6.10.0: missing cast in /usr/include/xfs/xfs_fs.h(xfs_getparents_next_rec) causes error in C++ compilations
Date: Tue, 27 Aug 2024 22:30:54 +0000 [thread overview]
Message-ID: <bug-219203-201763-9PynOwJ3m5@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-219203-201763@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=219203
--- Comment #2 from Darrick J. Wong (djwong@kernel.org) ---
On Wed, Aug 28, 2024 at 07:40:15AM +1000, Dave Chinner wrote:
> On Tue, Aug 27, 2024 at 09:07:03PM +0000, bugzilla-daemon@kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=219203
> >
> > Bug ID: 219203
> > Summary: xfsprogs-6.10.0: missing cast in
> > /usr/include/xfs/xfs_fs.h(xfs_getparents_next_rec)
> > causes error in C++ compilations
> > Product: File System
> > Version: 2.5
> > Hardware: All
> > OS: Linux
> > Status: NEW
> > Severity: normal
> > Priority: P3
> > Component: XFS
> > Assignee: filesystem_xfs@kernel-bugs.kernel.org
> > Reporter: kernel@mattwhitlock.name
> > Regression: No
> >
> > C allows implicit casts from void* to any pointer type, but C++ does not.
> Thus,
> > when including <xfs/xfs_fs.h> in a C++ compilation unit, the compiler
> raises
> > this error:
> >
> > /usr/include/xfs/xfs_fs.h: In function 'xfs_getparents_rec*
> > xfs_getparents_next_rec(xfs_getparents*, xfs_getparents_rec*)':
> > /usr/include/xfs/xfs_fs.h:915:16: error: invalid conversion from 'void*' to
> > 'xfs_getparents_rec*' [-fpermissive]
> > 915 | return next;
> > | ^~~~
> > | |
> > | void*
> >
> >
> > The return statement in xfs_getparents_next_rec() should have used an
> explicit
> > cast, as the return statement in xfs_getparents_first_rec() does.
> >
> > --- /usr/include/xfs/xfs_fs.h
> > +++ /usr/include/xfs/xfs_fs.h
> > @@ -912,7 +912,7 @@
> > if (next >= end)
> > return NULL;
> >
> > - return next;
> > + return (struct xfs_getparents_rec *)next;
> > }
>
> We shouldn't be putting static inline code in xfs_fs.h. That header
> file is purely for kernel API definitions. Iterator helper functions
> aren't part of the kernel API definition - they should be in some
> other exported header file if they are needed at all. The helpers
> could be defined in the getparents man page in the example code that
> uses them rather than exposing the C code to the world...
>
> I note that we've recently added a static inline function type
> checking function to xfs_types.h rather than it being an external
> function declaration, so there's more than one header file that
> needs cleanup....
XFS has been exporting tons of static inline functions via xfslibs-dev
for ages:
$ grep static.*inline /usr/include/xfs/ | wc -l
103
And the kernel itself has been doing that for years:
$ grep static.*inline /usr/include/linux/ | wc -l
348
...most of which don't trip g++ errors. This was the first thing that
broke a build somewhere, because neither the kernel nor xfsprogs use
the C++ compiler.
Shouldn't code review have caught these kinds of problems? Why wasn't
there any automated testing to identify these issues before they got
merged? How many more guardrails do I get to build??
Or: should we add a dummy cpp source file to xfsprogs that includes
xfs.h so that developers have some chance of finding potential C++
errors sooner than 6 weeks after the kernel release?
So far as I can tell, this fixes the c++ compilation errors, at least
with gcc 12:
diff --git a/libxfs/xfs_fs.h b/libxfs/xfs_fs.h
index 0613239cad13..8fc305cce06b 100644
--- a/libxfs/xfs_fs.h
+++ b/libxfs/xfs_fs.h
@@ -971,13 +971,13 @@ static inline struct xfs_getparents_rec *
xfs_getparents_next_rec(struct xfs_getparents *gp,
struct xfs_getparents_rec *gpr)
{
- void *next = ((void *)gpr + gpr->gpr_reclen);
+ void *next = ((char *)gpr + gpr->gpr_reclen);
void *end = (void *)(uintptr_t)(gp->gp_buffer + gp->gp_bufsize);
if (next >= end)
return NULL;
- return next;
+ return (struct xfs_getparents_rec *)next;
}
--D
> -Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2024-08-27 22:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 21:07 [Bug 219203] New: xfsprogs-6.10.0: missing cast in /usr/include/xfs/xfs_fs.h(xfs_getparents_next_rec) causes error in C++ compilations bugzilla-daemon
2024-08-27 21:40 ` Dave Chinner
2024-08-27 22:30 ` Darrick J. Wong
2024-08-28 0:10 ` Dave Chinner
2024-08-27 21:40 ` [Bug 219203] " bugzilla-daemon
2024-08-27 22:30 ` bugzilla-daemon [this message]
2024-08-27 23:12 ` bugzilla-daemon
2024-08-28 0:10 ` bugzilla-daemon
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=bug-219203-201763-9PynOwJ3m5@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=linux-xfs@vger.kernel.org \
/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.