All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manish Singh <manish.singh@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] Re: [Ocfs2-commits] manish commits r2175 - in trunk/fs/ocfs2: . cluster dlm
Date: Tue Apr 26 03:18:36 2005	[thread overview]
Message-ID: <20050426081538.GA6750@ca-server1.us.oracle.com> (raw)
In-Reply-To: <20050426071825.GA17901@lst.de>

On Tue, Apr 26, 2005 at 09:18:26AM +0200, Christoph Hellwig wrote:
> On Mon, Apr 25, 2005 at 10:23:12PM -0500, svn-commits@oss.oracle.com wrote:
> > Log:
> > Define MLFu64 and friends, for portable format strings for sized 64-bit types.
> > This gets rid of the tons on warnings on ia64 and ppc64.
> 
> Standard kernel practice is to cast a u64 to unsigned long (and a s64 to
> long), and not using such obsfucation.  I'd strongly suggest to follow
> that lead in ocfs.

I assume you meant to say "unsigned long long" and "long long".

The issue here is format string readability vs. printk argument
readability. Both magic format defines and verbose (unsigned long long)
casts make the code harder to read. Why is format string readability
preferred?

The nice thing about Documentation/CodingStyle is that it provides
cogent rationales for each of coding style precepts. I'm perfectly
willing to entertain the idea that magic format defines are horrible,
but having a good "why" helps the idea take root.


-Manish

  reply	other threads:[~2005-04-26  3:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200504260323.j3Q3NC9V013089@oss.oracle.com>
2005-04-26  2:18 ` [Ocfs2-devel] Re: [Ocfs2-commits] manish commits r2175 - in trunk/fs/ocfs2: . cluster dlm Christoph Hellwig
2005-04-26  3:18   ` Manish Singh [this message]
2005-04-26  3:25     ` Christoph Hellwig
2005-04-26  3:52       ` Manish Singh
2005-04-26  3:58         ` Christoph Hellwig

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=20050426081538.GA6750@ca-server1.us.oracle.com \
    --to=manish.singh@oracle.com \
    --cc=ocfs2-devel@oss.oracle.com \
    /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.