From: Tim Wright <timw@splhi.com>
To: "J . A . Magallon" <jamagallon@able.es>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] gcc-3.0 warnings
Date: Fri, 23 Mar 2001 16:31:29 -0800 [thread overview]
Message-ID: <20010323163129.B2534@kochanski.internal.splhi.com> (raw)
In-Reply-To: <20010323162956.A27066@ganymede.isdn.uiuc.edu> <Pine.LNX.4.31.0103231433380.766-100000@penguin.transmeta.com> <20010323235909.C3098@werewolf.able.es>
In-Reply-To: <20010323235909.C3098@werewolf.able.es>; from jamagallon@able.es on Fri, Mar 23, 2001 at 11:59:09PM +0100
On Fri, Mar 23, 2001 at 11:59:09PM +0100, J . A . Magallon wrote:
>
> On 03.23 Linus Torvalds wrote:
> >
> > I agree. I'd much prefer that syntax also.
> >
> > Or just remove the "default:" altogether, when it doesn't make any
> > difference.
> >
>
> Well, at last some sense. The same is with that ugly out: at the end
> of the function. Just change all that 'goto out' for a return.
> It does not matter, -O2 is going to do what it wants.
>
This has nothing to do with fastpathing and object code optimization. C
doesn't have exception handling, so you either have to remember to undo
allocations etc. in failure cases all through the code, or you stick your
undo code at the end of the function and have all failure cases jump to the
relevant label. It's not pretty, but it's much less error-prone e.g.
func()
{
error = 0;
a = alloc_something();
if (some failure) {
error = XXX;
goto out;
}
b = alloc_something_else();
if (some other failure) {
error = YYY;
goto out1;
}
...
out1:
dealloc(b);
out:
dealloc(a);
return(error);
}
This is arguably easier to follow and less likely to get broken than the
alternative of embedding all the unwind code at each error point.
Tim
--
Tim Wright - timw@splhi.com or timw@aracnet.com or twright@us.ibm.com
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
next prev parent reply other threads:[~2001-03-24 0:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-23 0:11 [PATCH] gcc-3.0 warnings J . A . Magallon
2001-03-23 0:28 ` Alan Cox
2001-03-23 0:38 ` J . A . Magallon
2001-03-23 9:29 ` Tim Waugh
2001-03-23 23:56 ` Ingo Oeser
2001-03-23 22:29 ` Bill Wendling
2001-03-23 22:34 ` Linus Torvalds
2001-03-23 22:59 ` J . A . Magallon
2001-03-24 0:31 ` Tim Wright [this message]
2001-03-24 0:42 ` Andrew Morton
2001-03-24 0:55 ` J . A . Magallon
2001-03-24 21:51 ` Tim Waugh
2001-03-24 1:16 ` Stephen Satchell
2001-03-26 14:25 ` Tim Wright
2001-03-24 5:30 ` Ion Badulescu
2001-03-23 17:12 ` Horst von Brand
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=20010323163129.B2534@kochanski.internal.splhi.com \
--to=timw@splhi.com \
--cc=jamagallon@able.es \
--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