On Tue, 2026-03-03 at 10:16 -0500, Theodore Tso wrote:

On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:

quoted

Like I said to Ted, this is just temporary scaffolding for the change.
The PRIino macro is removed in the end. Given that, perhaps you can
overlook the bikeshed's color in this instance?

I didn't realize that this was going to disappear in the end.  That
makes me feel much better about the change.  I'd suggest changing the
commit description where it claims that we're using something that
follows the inttypes.h convention and making it clear that this is
temporary and only to preserve bisectability.

One question though --- are there *really* places that are using
signed inode numbers and trying to print them?  If people are trying
to use negative inodes to signal an error or some such, the it implies
that at least for some file systems, an inode number larger than 2**63
might be problematic.  If there is core VFS code that uses a negative
inode number then this could be a real potential trap.

So are there really code which is doing a printf of 'PRIino "d"'?  Or
was this to allow the use of of 'PRiino "x"'?

Mostly it's to allow 'PRIino "x"'. There are a number of places that
(for whatever reason) print the inode number in hex. I don't want to
change those.

There are also some places that print it as a signed value (PRIino
"d"). I suspect most of those are bugs, or just holdovers from a
simpler time when we didn't worry so much about the signedness of inode
numbers. I fixed a few of those in the context of this series, fwiw.

-- 
Jeff Layton [off-list ref]