lkml.org 
[lkml]   [2003]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    SubjectRe: Question about style when converting from K&R to ANSI C.
    From
    Date
    On Sun, 2003-06-01 at 20:09, Linus Torvalds wrote:
    > In article <20030601132626.GA3012@work.bitmover.com>,
    > Larry McVoy <lm@bitmover.com> wrote:
    > >On Sat, May 31, 2003 at 11:56:16PM -0600, Steven Cole wrote:
    > >> Proposed conversion:
    > >>
    > >> int foo(void)
    > >> {
    > >> /* body here */
    > >> }
    > >
    > >Sometimes it is nice to be able to see function names with a
    > >
    > > grep '^[a-zA-Z].*(' *.c
    > >
    > >which is why I've always preferred
    > >
    > >int
    > >foo(void)
    > >{
    > > /* body here */
    > >}
    >
    > That makes no sense.
    >
    > Do you write your normal variable definitions like
    >
    > int
    > a,b,c;
    >
    > too? No you don't, because that would be totally idiotic.
    >
    > A function declaration is no different. The type of the function is very
    > important to the function itself (along with the arguments), and I
    > personally want to see _all_ of it when I grep for functions.
    >
    > You should just do
    >
    > grep -i '^[a-z_ ]*(' *.c
    >
    > and you'll get a nice function declaration with the standard kernel
    > coding style.
    >
    > And I personally don't normally do "grep for random function
    > declarations", that just sounds like a contrieved example. I grep for
    > specific function names to find usage, and then it's _doubly_ important
    > to see that the return (and argument) types match and make sense.
    >
    > So I definitely prefer all the arguments on the same line too, even if
    > that makes the line be closer to 100 chars than 80. The zlib K&R->ANSI
    > conversion was a special case, and I'd be happy if somebody were to have
    > the energy to convert it all the way (which implies moving comments
    > around etc).
    >
    How is this? I don't know about the energy part as xor'ed with itself
    leaves the value unchanged right now.

    I've tried to follow Documentation/kernel-doc-nano-HOWTO.txt
    as suggested by acme.

    Putting all the arguments on the same line gives 103 characters, if I
    counted correctly. Others will be longer, so this is chosen as a folded
    example.

    Steven

    --- linux/lib/zlib_inflate/inftrees.c.orig 2003-06-01 20:50:57.000000000 -0600
    +++ linux/lib/zlib_inflate/inftrees.c 2003-06-01 20:58:51.000000000 -0600
    @@ -288,14 +288,17 @@
    return y != 0 && g != 1 ? Z_BUF_ERROR : Z_OK;
    }

    +/**
    + * zlib_inflate_trees_bits:
    + * @uIntf *c: 19 code lengths
    + * @uIntf *bb: bits tree desired/actual depth
    + * @inflate_huft * FAR *tb: bits tree result
    + * @inflate_huft *hp: space for trees
    + * @z_streamp z: for messages
    + */

    -int zlib_inflate_trees_bits(
    - uIntf *c, /* 19 code lengths */
    - uIntf *bb, /* bits tree desired/actual depth */
    - inflate_huft * FAR *tb, /* bits tree result */
    - inflate_huft *hp, /* space for trees */
    - z_streamp z /* for messages */
    -)
    +int zlib_inflate_trees_bits(uIntf *c, uIntf *bb, inflate_huft * FAR *tb,
    + inflate_huft *hp, z_streamp z)
    {
    int r;
    uInt hn = 0; /* hufts used in space */


    -
    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:35    [W:0.029 / U:0.016 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site