Re: any chance of 2.6.0-test*?

Ryan Anderson
2003-01-13T03:39:44Z

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