mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: "Edgar, Bob" <Bob.Edgar@commerzbankib.com>,
	"'Jesper Juhl'" <juhl-lkml@dif.dk>,
	Steve French <sfrench@us.ibm.com>,
	Luca Tettamanti <kronos@kronoz.cjb.net>,
	samba-technical <samba-technical@lists.samba.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Domen Puncer <domen@coderock.org>
Subject: Re: [PATCH] whitespace cleanups for fs/cifs/file.c
Date: Mon, 7 Mar 2005 11:32:50 +0100	[thread overview]
Message-ID: <20050307103250.GC2198@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <20050307102846.GF27352@schnapps.adilger.int>

On Mon, 7 March 2005 03:28:46 -0700, Andreas Dilger wrote:
> 
> Ironically, the whitespace patch gets the small things right, but misses
> on the big readability issues, such as cifs_open() being 220 lines long
> and having a _really_ hard time staying inside 80 columns because of so
> many levels of nested conditionals.
> 
> Judicious use of gotos and some helper functions would help a lot
> here (e.g.  after CIFSSMBOpen() "if (rc) { ... goto out; }" and
> "if (!file->private_data) goto out;", would avoid indenting the rest
> of the function 16 columns.  Adding a couple helper functions like
> "cifs_convert_flags()" to return desiredAccess and disposition, and
> "cifs_init_private_data()" to allocate ->private_data and initialize
> the masses of fields would be good.
> 
> Is it possible that pCifsInode can ever be NULL???  Similarly, "if (buf)"
> on line 196 is needless, as it has already been checked on line 153
> (and we abort in that case).  Also, kfree() can handle NULL pointers.

Jesper knows those problems already (at least some of them).  Right
now, his biggest problem appears to be patch submission.  As soon as
Steve accepts his patches and the backlog is shrinking, he might get
to those issues, one at a time.

Unless my glass ball needs cleaning again.  Jesper? ;)

Jörn

-- 
The competent programmer is fully aware of the strictly limited size of
his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague. 
-- Edsger W. Dijkstra

  reply	other threads:[~2005-03-07 10:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-07  9:26 Edgar, Bob
2005-03-07 10:28 ` Jörn Engel
2005-03-07 10:28 ` Andreas Dilger
2005-03-07 10:32   ` Jörn Engel [this message]
2005-03-08  3:33     ` Jesper Juhl
2005-03-08  3:31   ` Jesper Juhl
2005-03-07 10:30 ` Domen Puncer
  -- strict thread matches above, loose matches on Subject: below --
2005-03-04 19:23 Jesper Juhl
2005-03-04 19:45 ` Christopher R. Hertel
2005-03-04 19:49   ` Jesper Juhl

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=20050307103250.GC2198@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=Bob.Edgar@commerzbankib.com \
    --cc=domen@coderock.org \
    --cc=juhl-lkml@dif.dk \
    --cc=kronos@kronoz.cjb.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=samba-technical@lists.samba.org \
    --cc=sfrench@us.ibm.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 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®