public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Sam James <sam@gentoo.org>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	kernel@mattwhitlock.name, linux-xfs@vger.kernel.org, hch@lst.de
Subject: Re: [RFC PATCH] libxfs: compile with a C++ compiler
Date: Wed, 28 Aug 2024 18:30:03 -0700	[thread overview]
Message-ID: <202408281827.14F35138B@keescook> (raw)
In-Reply-To: <87y14g9o7i.fsf@gentoo.org>

On Thu, Aug 29, 2024 at 01:17:53AM +0100, Sam James wrote:
> "Darrick J. Wong" <djwong@kernel.org> writes:
> 
> > On Wed, Aug 28, 2024 at 01:01:31AM +0100, Sam James wrote:
> >> "Darrick J. Wong" <djwong@kernel.org> writes:
> >> 
> >> > From: Darrick J. Wong <djwong@kernel.org>
> >> >
> >> > Apparently C++ compilers don't like the implicit void* casts that go on
> >> > in the system headers.  Compile a dummy program with the C++ compiler to
> >> > make sure this works, so Darrick has /some/ chance of figuring these
> >> > things out before the users do.
> >> 
> >> Thanks, this is a good idea. Double thanks for the quick fix.
> >> 
> >> 1) yes, it finds the breakage:
> >> Tested-by: Sam James <sam@gentoo.org>
> >> 
> >> 2) with the fix below (CC -> CXX):
> >> Reviewed-by: Sam James <sam@gentoo.org>
> >> 
> >> 3) another thing to think about is:
> >> * -pedantic?
> >
> > -pedantic won't build because C++ doesn't support flexarrays:
> >
> > In file included from ../include/xfs.h:61:
> > ../include/xfs/xfs_fs.h:523:33: error: ISO C++ forbids flexible array member ‘bulkstat’ [-Werror=pedantic]
> >   523 |         struct xfs_bulkstat     bulkstat[];
> >       |                                 ^~~~~~~~
> >
> > even if you wrap it in extern "C" { ... };
> 
> Doh. So the ship has kind of sailed already anyway.
> 
> >
> >> * maybe do one for a bunch of standards? (I think systemd does every
> >> possible value [1])
> >
> > That might be overkill since xfsprogs' build system doesn't have a good
> > mechanism for detecting if a compiler supports a particular standard.
> > I'm not even sure there's a good "reference" C++ standard to pick here,
> > since the kernel doesn't require a C++ compiler.
> >
> >> * doing the above for C as well
> >
> > Hmm, that's a good idea.
> >
> > I think the only relevant standard here is C11 (well really gnu11),
> > because that's what the kernel compiles with since 5.18.  xfsprogs
> > doesn't specify any particular version of C, but perhaps we should match
> > the kernel every time they bump that up?
> 
> Projects are often (IMO far too) conservative with the features they use
> in their headers and I don't think it's unreasonable to match the kernel
> here.
> 
> >
> > IOWs, should we build xfsprogs with -std=gnu11?  The commit changing the
> > kernel to gnu11 (e8c07082a810) remarks that gcc 5.1 supports it just
> > fine.  IIRC RHEL 7 only has 4.8.5 but it's now in extended support so
> > ... who cares?  The oldest supported Debian stable has gcc 8.
> 
> so, I think we should match whatever linux-headers / the uapi rules are,
> and given I've seen flexible array members in there, it's at least C99.
> 
> I did some quick greps and am not sure if we're using any C11 features
> in uapi at least.

-std=gnu11 seems like the correct choice, yes.

> Just don't blame me if someone yells ;)
> 
> (kees, any idea if I'm talking rubbish?)
> 
> tl;dr: let's try gnu11?
> 
> > [...]
> 
> sam

In really ugly cases (i.e. MSVC importing headers into a C++ project in
ACPICA) we did things like:

#if defined(__cplusplus)
# define __FLEX_SIZE	0
#else
# define __FLEX_SIZE	/**/
#endif

...
struct ... {
	...
	struct xfs_bulkstat     bulkstat[__FLEX_SIZE];
	...
};

-- 
Kees Cook

  reply	other threads:[~2024-08-29  1:30 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-27 23:33 [PATCHSET v4.1] xfs: cleanups for inode rooted btree code Darrick J. Wong
2024-08-27 23:33 ` [PATCH 01/10] xfs: fix C++ compilation errors in xfs_fs.h Darrick J. Wong
2024-08-28  4:09   ` Christoph Hellwig
2024-08-29  1:29   ` Dave Chinner
2024-09-02 15:20   ` Carlos Maiolino
2024-08-27 23:34 ` [PATCH 02/10] xfs: fix FITRIM reporting again Darrick J. Wong
2024-08-28  4:10   ` Christoph Hellwig
2024-08-27 23:34 ` [PATCH 03/10] xfs: fix a sloppy memory handling bug in xfs_iroot_realloc Darrick J. Wong
2024-08-28  4:10   ` Christoph Hellwig
2024-08-27 23:34 ` [PATCH 04/10] xfs: replace shouty XFS_BM{BT,DR} macros Darrick J. Wong
2024-08-28  4:11   ` Christoph Hellwig
2024-08-29  2:00   ` Dave Chinner
2024-08-29 22:10     ` Darrick J. Wong
2024-08-30  3:43       ` Christoph Hellwig
2024-08-27 23:35 ` [PATCH 05/10] xfs: move the zero records logic into xfs_bmap_broot_space_calc Darrick J. Wong
2024-08-28  4:14   ` Christoph Hellwig
2024-08-29  1:15     ` Darrick J. Wong
2024-08-29  3:51       ` Christoph Hellwig
2024-08-29  2:05     ` Dave Chinner
2024-08-29 22:34       ` Darrick J. Wong
2024-08-27 23:35 ` [PATCH 06/10] xfs: refactor the allocation and freeing of incore inode fork btree roots Darrick J. Wong
2024-08-28  4:15   ` Christoph Hellwig
2024-08-28  4:17   ` Christoph Hellwig
2024-08-28 21:50     ` Darrick J. Wong
2024-08-27 23:35 ` [PATCH 07/10] xfs: refactor creation of bmap " Darrick J. Wong
2024-08-28  4:19   ` Christoph Hellwig
2024-08-29  2:13   ` Dave Chinner
2024-08-29 22:46     ` Darrick J. Wong
2024-08-27 23:35 ` [PATCH 08/10] xfs: hoist the code that moves the incore inode fork broot memory Darrick J. Wong
2024-08-28  4:20   ` Christoph Hellwig
2024-08-29  2:54   ` Dave Chinner
2024-08-29 23:35     ` Darrick J. Wong
2024-08-27 23:36 ` [PATCH 09/10] xfs: rearrange xfs_iroot_realloc a bit Darrick J. Wong
2024-08-28  4:21   ` Christoph Hellwig
2024-08-27 23:36 ` [PATCH 10/10] xfs: standardize the btree maxrecs function parameters Darrick J. Wong
2024-08-28  4:21   ` Christoph Hellwig
2024-08-27 23:45 ` [RFC PATCH] libxfs: compile with a C++ compiler Darrick J. Wong
2024-08-28  0:01   ` Sam James
2024-08-28  0:10     ` Sam James
2024-08-28 23:53     ` Darrick J. Wong
2024-08-29  0:17       ` Sam James
2024-08-29  1:30         ` Kees Cook [this message]
2024-08-28  4:25   ` Christoph Hellwig

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=202408281827.14F35138B@keescook \
    --to=kees@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=kernel@mattwhitlock.name \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sam@gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox