mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ralph Corderoy <ralph@inputplus.co.uk>
To: Domen Puncer <domen@coderock.org>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org,
	isdn4linux@listserv.isdn4linux.de, jlamanna@gmail.com
Subject: Re: [patch 1/8] isdn_bsdcomp.c - vfree() checking cleanups
Date: Mon, 07 Mar 2005 11:06:40 +0000	[thread overview]
Message-ID: <200503071106.j27B6fE05365@blake.inputplus.co.uk> (raw)
In-Reply-To: <20050307002133.GG32564@nd47.coderock.org>


Hi Domen,

> On 07/03/05 00:07 +0000, Ralph Corderoy wrote:
> > > -		if (db->dict) {
> > > -			vfree (db->dict);
> > > -			db->dict = NULL;
> > > -		}
> > > +		vfree (db->dict);
> > > +		db->dict = NULL;
> > 
> > Is it really worth always calling vfree() which calls __vunmap()
> > before db->dict is determined to be NULL in order to turn three
> > lines into two?
> 
> Four lines into two :-)
> 
> > Plus the write to db->dict which might otherwise not be needed.  The
> > old code was clear, clean, and fast, no?
> 
> Shorter and more readable code is always better, right?

No.  Let me try and persuade you.

There's three cases.

    1.  foo will always be NULL at the line in question so no need to
    `vfree(foo); foo = NULL;'.

    2.  foo will never be NULL at the line in question so `vfree(foo);
    foo = NULL;' is mandatory.

    3.  foo will sometimes be NULL, sometimes not.

In that third case, seeing

    if (foo) {
        vfree(foo);
        foo = NULL;
    }

tells the reader that we're dealing with the `foo *maybe* NULL' case
whereas

    vfree(foo);
    foo = NULL;

*suggests* the `foo is never NULL' case.  The reader has to remember
that vfree(NULL) is valid and bear that in mind.

If the reader is about to modify the preceeding lines, knowing the foo
may sometimes be NULL helps.  So I prefer the longer code here because
it better shows the intent of the coder and is more telling about the
state of db->dict.

If you're really keen to save lines, please axe the superfluous
three-line comments.  We read C here, they're unnecessary.

>  		/*
>  		 * Release the dictionary
>  		 */
> -		if (db->dict) {
> -			vfree (db->dict);
> -			db->dict = NULL;
> -		}
> +		vfree (db->dict);
> +		db->dict = NULL;
>  
>  		/*
>  		 * Release the string buffer
>  		 */
> -		if (db->lens) {
> -			vfree (db->lens);
> -			db->lens = NULL;
> -		}
> +		vfree (db->lens);
> +		db->lens = NULL;
>  
>  		/*
>  		 * Finally release the structure itself.

Cheers,


Ralph.


      parent reply	other threads:[~2005-03-07 11:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-06 22:37 domen
2005-03-07  0:07 ` Ralph Corderoy
2005-03-07  0:21   ` Domen Puncer
2005-03-07 10:26     ` Karsten Keil
2005-03-07 11:06     ` Ralph Corderoy [this message]

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=200503071106.j27B6fE05365@blake.inputplus.co.uk \
    --to=ralph@inputplus.co.uk \
    --cc=akpm@osdl.org \
    --cc=domen@coderock.org \
    --cc=isdn4linux@listserv.isdn4linux.de \
    --cc=jlamanna@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®