public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ionut Alexa <ionut.m.alexa@gmail.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel:signal.c Fix coding style errors and warnings.
Date: Sun, 16 Nov 2014 18:01:00 +0000	[thread overview]
Message-ID: <20141116180059.GS7996@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAKF-a2AhmE4iZHsRNgyp6Le6uaDNSUjbxQENm5sTYD3f24ORnA@mail.gmail.com>

On Sun, Nov 16, 2014 at 07:28:29PM +0200, Ionut Alexa wrote:
> I worked a while in critical automotive software application. There is
> nothing more important than to know your program is running start-to-end in
> the correct order. For the automotive indurstri is safety critical. For PC
> application is not madatory. But for Operating systems, it is a good
> practice. If the function exits from a diferent point depending on some
> conditions, it is hard to debug when the kernel behavior is not the
> expected one.

Excuse me, but this is pure cargo-cult argument.  There is a lot more to
complexity of debugging than blind application of rules like that.  Sure,
the control flow graph affects it.  However, proposed change ("replace
all returns with goto to the end") is not an improvement at all.

There are reasons behind these practices; applying them without understanding
those is not going to work.  And the reasons behind the "single exit point
is better" apply to those goto just as well as they did to those return;
control flow remains the same, after all.

  parent reply	other threads:[~2014-11-16 18:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-14 15:56 [PATCH] kernel:signal.c Fix coding style errors and warnings Ionut Alexa
2014-11-16  2:47 ` Al Viro
     [not found]   ` <CAKF-a2AYAPy2ENaFVanFCWZ_sXHPy_K_uH6zo5apT-kLLaqONA@mail.gmail.com>
2014-11-16 17:08     ` Al Viro
     [not found]       ` <CAKF-a2AhmE4iZHsRNgyp6Le6uaDNSUjbxQENm5sTYD3f24ORnA@mail.gmail.com>
2014-11-16 18:01         ` Al Viro [this message]
2014-11-16 20:09           ` [UNNECESSARY PATCH 00/16] signal: coding style wankery Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 01/16] signal: whitespace neatening Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 02/16] signal: vertical line neatening Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 03/16] signal: Move EXPORT_SYMBOL after function definition Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 04/16] signal: Use pr_<level> Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 05/16] signal: Move case statements to separate lines and for loop neatening Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 06/16] signal: Use consistent function definition style Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 07/16] signal: Add braces Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 08/16] signal: Remove unnecessary return Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 09/16] signal: Use include <linux not <asm Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 10/16] signal: Remove unnecessary parentheses from function pointer call Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 11/16] signal: Add parenthese around sizeof argument Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 12/16] signal: 80 column wrapping Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 13/16] signal: Move label to first column Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 14/16] signal: Convert for (;;) to do {} while Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 15/16] signal: Isolate returns by adding blank lines Joe Perches
2014-11-16 20:09             ` [UNNECESSARY PATCH 16/16] signal: Coalesce kdb_printf formats Joe Perches

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=20141116180059.GS7996@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=ionut.m.alexa@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