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/
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:43 EST