Messages in this thread Patch in this message | | | Date | Sun, 12 Jan 2003 22:48:13 -0500 | From | Ryan Anderson <> | Subject | Re: any chance of 2.6.0-test*? |
| |
On Sun, Jan 12, 2003 at 08:21:50PM -0500, Rob Wilkens wrote: > :/usr/src/linux-2.5.56/Documentation# grep -i return CodingStyle > > Returned nothing..
As annoying as this thread is, there are occassional valid points.
A first pass at an addition:
--- local/Documentation/CodingStyle.orig 2002-11-19 03:02:32.000000000 -0500 +++ local/Documentation/CodingStyle 2003-01-12 22:44:39.000000000 -0500 @@ -264,3 +264,27 @@ Remember: if another thread can find your data structure, and you don't have a reference count on it, you almost certainly have a bug. + + Chapter 9: Error handling + +Error handling in functions needs to follow a few simple rules. If the +function has allocated resources (irqs, memory), taken a reference, +grabbed locks, etc, all of those allocations must be reversed when +returning an error. + +In functions that depend on several allocations, the preferred way to +return the error is with with the use of a few "goto"s that point at an +error block at the end of the function, after the normal, successful +return. + +Several consecutive lables can be used, reversing the order of the +allocations. For example, if memory is allocated, a lock taken, and +an irq activated, the error labels might be labeled "err_noirq", +"err_nolock", "err_nomem", in order. The final step would be to +return the error. + +The reason for this style is very simple: Multiple return paths from +the same block of code are extremely confusing, and make verification +that locks are balanced, memory is properly freed, and that reference +counts are not leaked very difficult. +
--
Ryan Anderson sometimes Pug Majere - 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/
| |