Re: any chance of 2.6.0-test*?

[Ryan Anderson]

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