public inbox for linux-m68k@lists.linux-m68k.org
 help / color / mirror / Atom feed
From: "Christian T. Steigies" <cts@debian.org>
To: Wouter Verhelst <w@uter.be>
Cc: Thorsten Glaser <tg@mirbsd.de>,
	Michael Schmitz <schmitzmic@gmail.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-m68k@vger.kernel.org,
	Ingo J?rgensmann <ij@2012.bluespice.org>
Subject: Re: [PATCH 00/11] Atari Ethernet/USB patch series - for upstream and debian-kernel
Date: Sat, 30 Mar 2013 10:23:56 +0100	[thread overview]
Message-ID: <20130330092356.GA27328@chumley.earth.sol> (raw)
In-Reply-To: <51569301.9030507@uter.be>

Wouter,
On Sat, Mar 30, 2013 at 08:23:45AM +0100, Wouter Verhelst wrote:
> On 29-03-13 23:47, Christian T. Steigies wrote:
> > On Fri, Mar 29, 2013 at 09:38:31PM +0000, Thorsten Glaser wrote:
> >>
> >> Avoiding gotos for the purpose of avoiding gotos is absolutely
> >> silly (as the compiler translates them to jumps, which are the
> >> same in asm) and positively harmful (for the legibility of the
> >> code; I wish I had goto in mksh???).
> > 
> > From my Commodore Basic days I still know gotos and spaghetti. I know it
> > will be translated to jumps, but I thought we are programming in C and not
> > asm, because the readability is better. But maybe I just read too much about
> > python recently ;-)
> 
> Goto in BASIC is not the same thing as goto in C. In BASIC, a goto
> statement can go all over the place. You see a goto, you don't know
> where you'll end up. Yes, that is spaghetti code.
> 
> In C, a goto can only jump within the same function. It's possible to
> overuse it, but error unwinding is one of the few cases where it's
> sensible and good to use it. Consider:
> 
> int handle = initialize_handle();
> if(connect_handle(handle)!=CONNECTION_OK) {
> 	unintialize_handle(handle);
> 	return ECONNFAILED;
> }
> if(send_greeting(handle)!=GREETING_OK) {
> 	uninitialize_handle(handle);
> 	return EGREETFAILED;
> }
> return HANDLE_OK;
> 
> This code works, and it's fairly clear what it does; but the problem
> here is that you replicate deinitialization code. If that
> deinitialization code ever needs to change, you have to change it in
> multiple places. You might miss one, causing you a leak of sorts. It's
> of course possible to nest the ifs, but that's even worse:
> 
> int handle = initialize_handle();
> int retval = HANDLE_OK;
> if(connect_handle(handle) != CONNECTION_OK) {
> 	retval = ECONNFAILED;
> } else {
> 	if(send_greeting(handle) != GREETING_OK) {
> 		retval = EGREETFAILED;
> 	}
> }
> uninitialize_handle(handle);
> return retval;
> 
> it's easy to see that this kind of code will become unreadable once
> you're past three or four of these checks. However, the compiled code
> will be *exactly* the same as the following:
> 
> int handle = initialize_handle();
> int retval = HANDLE_OK;
> if(connect_handle(handle) != CONNECTION_OK) {
> 	retval = ECONNFAILED;
> 	goto err_out;
> }
> if(send_greeting(handle) != GREETING_OK) {
> 	retval = EGREETFAILED;
> 	goto err_out;
> }
> err_out:
> uninitialize_handle(handle);
> return retval;
> 
> This is again as readable as the first example, but the deinitialization
> is grouped at the bottom of the function.

Thanks for the detailed example, do you want to teach me to be a kernel
hacker? :-)

I don't know too much C, but I have the feeling that in your last example
uninitialize_handle is called in any case, or are commands after the goto
lable skipped if you do not jump to them? If that is the case, I do not find
this more readable. I think the last lines of your example have to look like
this:

goto no_err;
err_out:
uninitialize_handle(handle);
no_err:
return retval;

And that in my exes is spaghetti... but I understand the rest of your
reasoning.

bon appetit!
Christian

  reply	other threads:[~2013-03-30  9:24 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-25  6:37 [PATCH 00/11] Atari Ethernet/USB patch series - for upstream and debian-kernel Michael Schmitz
2013-03-25  6:37 ` [PATCH 01/11] m68k/atari: ROM port ISA adapter support Michael Schmitz
2013-03-25  6:37 ` [PATCH 02/11] m68k/irq: Add handle_polled_irq() for timer based soft interrupts Michael Schmitz
2013-03-25  6:37 ` [PATCH 03/11] m68k/atari: use dedicated irq_chip for timer D interrupts Michael Schmitz
2013-03-25  6:37 ` [PATCH 04/11] m68k/atari: EtherNAT - platform device and IRQ support code Michael Schmitz
2013-03-25  6:37 ` [PATCH 05/11] m68k/atari: EtherNEC - add platform device support Michael Schmitz
2013-03-25  6:37 ` [PATCH 06/11] m68k/atari: EtherNAT - ethernet support - new driver (smc91x) Michael Schmitz
2013-03-25  6:37 ` [PATCH 07/11] m68k/atari: EtherNEC - ethernet support - new driver (ne.c) Michael Schmitz
2013-03-25  6:37 ` [PATCH 08/11] m68k/atari: EtherNAT - add interrupt chip definition for CPLD interrupts Michael Schmitz
2013-03-25  6:37 ` [PATCH 09/11] m68k: Implement ndelay() based on the existing udelay() logic Michael Schmitz
2013-03-25  6:37 ` [PATCH 10/11] m68k/atari: USB - add platform devices for EtherNAT/NetUSBee ISP1160 HCD Michael Schmitz
2013-03-25  6:37 ` [PATCH 11/11] m68k/atari: USB - add ISP1160 USB host controller support Michael Schmitz
2013-03-25 17:53 ` [PATCH 00/11] Atari Ethernet/USB patch series - for upstream and debian-kernel Thorsten Glaser
2013-03-25 21:25   ` Michael Schmitz
2013-03-26  8:12   ` Wouter Verhelst
2013-03-27  7:02     ` Michael Schmitz
2013-03-27  8:19       ` Geert Uytterhoeven
2013-03-28 22:40         ` Michael Schmitz
2013-03-27  8:57       ` Ingo Jürgensmann
2013-03-28  4:53         ` Michael Schmitz
2013-03-28 21:17       ` Christian T. Steigies
2013-03-28 22:36         ` Michael Schmitz
2013-03-28 23:10           ` Christian T. Steigies
2013-03-29  1:09             ` Michael Schmitz
2013-03-29  8:22               ` Christian T. Steigies
2013-03-29  7:56             ` Geert Uytterhoeven
2013-03-29  8:06               ` Christian T. Steigies
2013-03-29  8:30                 ` Geert Uytterhoeven
2013-03-29 18:46                   ` Michael Schmitz
2013-03-29 19:33                     ` Christian T. Steigies
2013-03-29 21:38                       ` Thorsten Glaser
2013-03-29 22:47                         ` Christian T. Steigies
2013-03-29 23:24                           ` Michael Schmitz
2013-03-30  0:00                             ` Ingo Jürgensmann
2013-03-30  0:11                               ` Ingo Jürgensmann
2013-03-30  1:37                               ` Michael Schmitz
2013-03-30  9:34                                 ` Ingo Jürgensmann
2013-03-30 10:23                             ` Geert Uytterhoeven
2013-03-30  7:23                           ` Wouter Verhelst
2013-03-30  9:23                             ` Christian T. Steigies [this message]
2013-03-30  8:14                           ` Andreas Schwab

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=20130330092356.GA27328@chumley.earth.sol \
    --to=cts@debian.org \
    --cc=geert@linux-m68k.org \
    --cc=ij@2012.bluespice.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=schmitzmic@gmail.com \
    --cc=tg@mirbsd.de \
    --cc=w@uter.be \
    /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