Re: [PATCHSET RFC v1.0 0/7] xfs: clean up realtime type usage

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, Oct 13, 2023 at 06:24:34AM +0200, Christoph Hellwig wrote:
> On Thu, Oct 12, 2023 at 03:30:00PM -0700, Darrick J. Wong wrote:
> > The primary advantage that I can think of is code readability -- all the
> > xfs_*rtb_ functions take xfs_rtblock_t types, and you can follow them
> > all the way through the rt allocator/rmap/refcount code.  xfs_rtblock_t
> > is a linear quantity even with rtgroups turned on.
> > 
> > The gross part is that one still has to know that br_startblock can be
> > either xfs_fsblock_t or xfs_rtblock_t depending on inode and whichfork.
> 
> Yeah.
> 
> > That said, I don't think gcc actually warns about silent casts from
> > xfs_fsblock_t to xfs_rtblock_t.
> 
> 
> typedefs in C are syntactix shugar.  You will never get a warning about
> mixing typedefs for the same underlying type (and often also not for
> mixing with other integer types).  Having an annotation for a strong
> typedef that can only do arithmetic on itself without casts or special
> annotations would be really handy, though.

We can do it crappily in C with __bitwise and letting the static checker
bots go wild.  Some day when someone rewrites the entire codebase in
Rust (HA!) then we'll be able to do:

struct xfs_fsblock_t(u64);
struct xfs_agblock_t(u32);

and (to the extent that I understand Rust) the Rust compiler will
complain about stuffing xfs_agblock_t into an xfs_fsblock_t without a
proper conversion.

--D