Re: goto's ???

Khimenko Victor (khim@sch57.msk.ru)
Tue, 25 May 1999 19:47:57 +0400 (MSD)


In <Pine.LNX.4.10.9905230226130.1577-100000@tt1.labf.org> Mofeed Shahin (shahin@labf.org) wrote:

> G'day all,

> I was just have a bit of a look at the fs code, and noticed something a
> little odd. There are alot of 'goto' statements in the code. From what I
> can see they are not needed.

> eg :
> line 632 of /usr/src/linux/fs/open.c :

> struct file *filp_open(const char * filename, int flags, int mode)
> {
> struct inode * inode;
> struct dentry * dentry;
> struct file * f;
> int flag,error;

> error = -ENFILE;
> f = get_empty_filp();
> if (!f)
> goto out;
> ....
> <SNIP>

> out:
> return ERR_PTR(error);
> }

> this seems like an extra jmp statement to me (unless the compiler
> optimises it)

> ie why not just do this :
> struct file *filp_open(const char * filename, int flags, int mode)
> {
> struct inode * inode;
> struct dentry * dentry;
> struct file * f;
> int flag,error;

> error = -ENFILE;
> f = get_empty_filp();
> if (!f)
> return ERR_PTR(error);
> ....
> <SNIP>
> }

Two words: "common path". It's typical way to handle errors in kernel:

/* do something */
if (/* error detected */) goto handle_error;
/* do what must be done if no error detected */
error_handled:
/* continue work */
handle_error:
/* do something to fix error */
goto error_handled;

Why two goto's if just "if" is sufficient ? It's simple: version with goto is
faster ! Why ? Since code used in most cases (when there are no errors detected)
are placed tighter... If there are just simple return statement this will buy us
nothing (but no loss in speed occurs as well :-) but if something will be
added this will make "common path" shorter...

P.S. Compiler can not do such optimization IN PRINCIPLE sinse it has no info
about "common path" :-(( Of course it's possible to extend "C" to make such
automatic optimization possible but it's not clear if such change is worthfull...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/