All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: linux-kernel@vger.kernel.org
Subject: [RFC] Easier printing of unknown-size quantities
Date: Thu, 9 Jan 2014 06:42:10 -0700	[thread overview]
Message-ID: <20140109134210.GC29910@parisc-linux.org> (raw)


We have a number of types whose sizes are architecture- or
config-dependent such as pgoff_t or sector_t.  The recommendation for
printing them is to cast them to (unsigned long long) and print them with
%Lu/%llx/...  That's entirely reasonable except that it's so verbose.
I was wishing that C had a more succinct way to express that, when it
struct me that we can fix this without changing the compiler or language
spec, viz:

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index ecb8754..011b55e 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -28,7 +28,7 @@
 #define LLONG_MIN	(-LLONG_MAX - 1)
 #define ULLONG_MAX	(~0ULL)
 #define SIZE_MAX	(~(size_t)0)
+#define ULL(x)		((unsigned long long)(x))
 
 #define STACK_MAGIC	0xdeadbeef
 

For demonstration purposes only (because I have another patch series
that would conflict with this):

diff --git a/fs/buffer.c b/fs/buffer.c
index 6024877..50e2596 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -148,7 +148,7 @@ static void buffer_io_error(struct buffer_head *bh)
 {
 	char b[BDEVNAME_SIZE];
 	printk(KERN_ERR "Buffer I/O error on device %s, logical block %Lu\n",
-			bdevname(bh->b_bdev, b),
-			(unsigned long long)bh->b_blocknr);
+			bdevname(bh->b_bdev, b), ULL(bh->b_blocknr));
 }
 
 /*
@@ -257,8 +256,7 @@ __find_get_block_slow(struct block_device *bdev, sector_t block)
 
 		printk("__find_get_block_slow() failed. "
 			"block=%llu, b_blocknr=%llu\n",
-			(unsigned long long)block,
-			(unsigned long long)bh->b_blocknr);
+			ULL(block), ULL(bh->b_blocknr));
 		printk("b_state=0x%08lx, b_size=%zu\n",
 			bh->b_state, bh->b_size);
 		printk("device %s blocksize: %d\n", bdevname(bdev, b),
@@ -1083,8 +1081,7 @@ grow_buffers(struct block_device *bdev, sector_t block, int size)
 		char b[BDEVNAME_SIZE];
 
 		printk(KERN_ERR "%s: requested out-of-range block %llu for "
-			"device %s\n",
-			__func__, (unsigned long long)block,
+			"device %s\n", __func__, ULL(block),
 			bdevname(bdev, b));
 		return -EIO;
 	}

Seems like a clear win to me.  What do others think?  Might create a bit
of churn, but I find the "after" version easier to read than the former.

This is an RFC, not a PATCH, so I have deliberately mangled the patches to
not apply.  I'm happy to supply working patches after we've bikeshedded
this one around a bit.  I'm also happy to introduce it, but forbid any
mass conversion patches for a year until code has had the chance to
start using it.

In fact, let me help start the bikeshedding.  I was trying to decide
what I wanted this to print:

	unsigned int x, y;
	x = y = 0x80000000;
	printf("%llx\n", ULL(x+y));

I decided that I didn't want to magically fix the overflow, but rather
expose it.  After all, if the user wants the promotion, they can always
write ULL(x)+y.  That's why there are extra parens in the definition
of ULL.

I also considered naming the macro Lu(x) so you could use it like this:

	printf("%Lu\n", Lu(x));

which is kind of cute, but it seemed clearer to me to name it the same
as the integer suffixes.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

             reply	other threads:[~2014-01-09 13:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 13:42 Matthew Wilcox [this message]
2014-01-09 18:14 ` [RFC] Easier printing of unknown-size quantities Joe Perches

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=20140109134210.GC29910@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.