linux-kernel - Re: A CodingStyle suggestion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 4 Feb 2007 07:57:43 -0500 (EST)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Theodore Tso <tytso@....edu>
cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	"Ahmed S. Darwish" <darwish.07@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: A CodingStyle suggestion

On Sun, 4 Feb 2007, Theodore Tso wrote:

> On Sat, Feb 03, 2007 at 01:59:51PM -0800, Randy Dunlap wrote:
> > On Sat, 3 Feb 2007 23:58:48 +0200 Ahmed S. Darwish wrote:
> > >
> > > In CodingStyle Chapter 16 "Function return value and names", why not
> > > adding a comment about the favorable community way of checking the return
> > > value. ie:
> > >
> > > ret = do_method();
> > > if (ret) {
> > >    /* deal with error */
> > > }
> > >
> > > and not other ways like:
> > >
> > > if (do_method()) or if ((ret = do_method()) > value) ...
> > >
> >
> > I like it.  Please cc: Andrew Morton <akpm@...l.org> on it.
> > Hopefully he will merge it.
> >
>
> I'm going to have to disagree.  Sometimes if the main flow of the code
> is down, it's actually better to do this:
>
> 	if ((err = do_foo()) < 0)
> 		return (err);
> 	if ((err = do_bar(current, filp)) < 0)
> 		return (err);
> 	if ((err = do_quux(filp, buffer)) < 0) {
> 		close(filp);
> 		return (err);
> 	}
>
> Than to do something like this:
>
> 	err = do_foo();
> 	if (err < 0)
> 		return (err);
> 	err = do_bar(current, filp);
> 	if (err < 0)
> 		return (err);
> 	err = do_quux(filp, buffer);
> 	if (err < 0) {
> 		close(filp);
> 		return (err);
> 	}
>
> The first is more concise, and it draws the reader's eye to what's
> really going on.  The cleanup/return error path is less important,
> and and it's pretty clear what's going on just from glancing at it.
>
> 						- Ted

i doubt you're going to get consensus on the *best* way to write this,
but it would be worthwhile to at least agree on the really *bad*
variations that shouldn't be used, the most vile one being:

  ret = whatever();
  if (ret) {
	...
  }

when there are no more references to "ret" inside the "if" construct,
which means there was no need to declare "ret" in the first place.

i'm guessing we can all agree on *that* but, beyond that, i think it's
going to be a matter of personal preference.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://www.fsdev.dreamhosters.com/wiki/index.php?title=Main_Page
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/