Re: Question about style when converting from K&R to ANSI C.

Steven Cole (elenstev@mesatop.com)
01 Jun 2003 21:15:27 -0600


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/