public inbox for backports@vger.kernel.org
 help / color / mirror / Atom feed
From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Arend van Spriel <arend@broadcom.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	Julia Lawall <julia.lawall@lip6.fr>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	Coccinelle <cocci@systeme.lip6.fr>,
	backports@vger.kernel.org,
	Johannes Berg <johannes@sipsolutions.net>,
	"Luis R. Rodriguez" <mcgrof@suse.com>
Subject: Re: [patch] CodingStyle: add some more error handling guidelines
Date: Thu, 04 Dec 2014 00:11:31 +0100	[thread overview]
Message-ID: <547F98A3.7090509@users.sourceforge.net> (raw)
In-Reply-To: <547F60E5.50705@broadcom.com>

> Please provide your point of view.

I would like to interpret the key word "goto" from the C programming
language a bit more here so that a better common understanding can
eventually be achieved.

Strong opinions might be floating around for the consistent naming
of jump labels. My reasoning works like the following.

This key word could also be interpreted as two items "go" and "to",
couldn't it?
How much does this variation stress its meaning in a specific direction?

Some software developers would like to express the reason about
an unexpected event at the jump source. But I guess that this approach
increases the risk for a popular story like "goto fail;", doesn't it?
I would prefer not to specify "go to failure".

So I find that there are more variants possible to stress the jump target.
Examples:
* Failure_exit
* out_memory_release
* unregister_item

Regards,
Markus

      reply	other threads:[~2014-12-03 23:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20141202085950.GA13434@mwanda>
2014-12-03 12:31 ` [patch] CodingStyle: add some more error handling guidelines SF Markus Elfring
2014-12-03 12:39   ` Arend van Spriel
2014-12-03 12:51     ` SF Markus Elfring
2014-12-03 12:45   ` Dan Carpenter
2014-12-03 12:52     ` Julia Lawall
2014-12-03 13:15       ` Dan Carpenter
2014-12-03 13:00     ` SF Markus Elfring
2014-12-03 13:20       ` Dan Carpenter
2014-12-03 13:24         ` SF Markus Elfring
2014-12-03 14:08           ` Arend van Spriel
2014-12-03 16:00             ` SF Markus Elfring
2014-12-03 19:13               ` Arend van Spriel
2014-12-03 23:11                 ` SF Markus Elfring [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=547F98A3.7090509@users.sourceforge.net \
    --to=elfring@users.sourceforge.net \
    --cc=arend@broadcom.com \
    --cc=backports@vger.kernel.org \
    --cc=cocci@systeme.lip6.fr \
    --cc=corbet@lwn.net \
    --cc=dan.carpenter@oracle.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=johannes@sipsolutions.net \
    --cc=julia.lawall@lip6.fr \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@suse.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