All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Pekka Enberg <penberg@kernel.org>
Cc: Sasha Levin <levinsasha928@gmail.com>,
	Prasad Joshi <prasadjoshi124@gmail.com>,
	kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com,
	chaitanyakulkarni15@gmail.com, ashwini.kulkarni@gmail.com,
	anupshendkar@gmail.com
Subject: Re: [PATCH v3] kvm tools: Add QCOW level2 caching support
Date: Fri, 3 Jun 2011 09:15:02 +0200	[thread overview]
Message-ID: <20110603071502.GD15375@elte.hu> (raw)
In-Reply-To: <BANLkTi=KWU=Fis-KmmObCVQu2tRwmfDmUw@mail.gmail.com>


* Pekka Enberg <penberg@kernel.org> wrote:

> On Fri, Jun 3, 2011 at 12:19 AM, Sasha Levin <levinsasha928@gmail.com> wrote:
> >> +static int cache_table(struct qcow *q, u64 *table, u64 offset)
> >> +{
> >> +     struct qcow_l2_cache *n;
> >> +     struct rb_root *r = &q->root;
> >> +     struct qcow_l2_cache *lru;
> >> +
> >> +     n = calloc(1, sizeof(struct qcow_l2_cache));
> >                        sizeof(*n)
> > sizeof() should use the variable name itself, not the data type. Check
> > out chapter 14 in 'Documentation/CodingStyle'.
> 
> Well, it doesn't matter that much, to be honest. 'n' could use a 
> better name, though - 'cache' or 'c'.

I personally prefer the sizeof(*cache) variant for a subtle reason: 
because during review it's easier to match up local variable names 
than to match up types.

For example when i review code i only look at the types once: i just 
establish their main nature and attach any semantic meaning to the 
local variable name.

So if 'later in the code' i see "sizeof(struct qcow_l2_cache)" i wont 
know it intuitively whether it matches up with 'cache' or not. So for 
example i might not notice such a bug:

	cache = calloc(1, sizeof(struct qcow_l1_cache));

(trivia: how many seconds does it take for you to notice the bug in 
the above line? Note, you already have the advantage that you *know* 
that there's a bug in that line :-)

Even if i noticed the bug, i'd notice it by looking back at the local 
variables defininition block - which is a distraction from reading 
the code flow itself.

But if it's written differently i will notice this bug immediately:

	cache = calloc(1, sizeof(*r));

i will even notice this pattern:

	cache = calloc(1, sizeof(cache));

I guess we could introduce a type-safe zalloc variant, something 
like:

	cache = zalloc_t(*cache);

Which is a clever macro that allocates sizeof(struct qcow_l2_cache) 
bytes and gives back a 'struct qcow_l2_cache *' typed result. That 
way this:

	cache = zalloc_t(r);

or this:

	cache = zalloc_t(cache);

Will result in a compiler error.

Hm?

Thanks,

	Ingo

  reply	other threads:[~2011-06-03  7:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-02 20:01 [PATCH v3] kvm tools: Add QCOW level2 caching support Prasad Joshi
2011-06-02 20:37 ` Pekka Enberg
2011-06-02 20:57   ` Prasad Joshi
2011-06-02 21:07     ` Pekka Enberg
2011-06-02 21:11 ` Pekka Enberg
2011-06-02 21:19 ` Sasha Levin
2011-06-03  5:56   ` Pekka Enberg
2011-06-03  7:15     ` Ingo Molnar [this message]
2011-06-03  7:23       ` Pekka Enberg

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=20110603071502.GD15375@elte.hu \
    --to=mingo@elte.hu \
    --cc=anupshendkar@gmail.com \
    --cc=ashwini.kulkarni@gmail.com \
    --cc=asias.hejun@gmail.com \
    --cc=chaitanyakulkarni15@gmail.com \
    --cc=gorcunov@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=levinsasha928@gmail.com \
    --cc=penberg@kernel.org \
    --cc=prasadjoshi124@gmail.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.