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: > > > > 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 <[email protected]>
