> However, I have always been taught, and have always believed that
> "goto"s are inherently evil. They are the creators of spaghetti code
If the main flow of the code is through a bunch of hard to trace
gotos and you choose to blame the tool instead of the programmer,
I guess you could blame goto.
However, the goto can also be a great tool to make the code more
readable. The goto statement is, IMHO, one of the more elegant
ways to code exceptions into a C function; that is, dealing with
error situations that don't happen very often, in such a way that
the error handling code doesn't clutter up the main code path.
As an example, you could look at fs/super.c::do_kern_mount()
mnt = alloc_vfsmnt(name);
if (!mnt)
goto out;
sb = type->get_sb(type, flags, name, data);
if (IS_ERR(sb))
goto out_mnt;
Do you see how the absence of the error handling cleanup code
makes the normal code path easier to read ?
regards,
Rik
-- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://guru.conectiva.com/ Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/