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
next prev parent 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