lkml.org 
[lkml]   [2003]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:32    [W:2.936 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site