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
