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

[Steven Cole]

On Sun, 2003-06-01 at 10:02, Larry McVoy wrote:
> > I have used more traditional style where the new Linus style was not
> > warranted.  Here is the patch for fs/jfs/jfs_xtree.c:
> > 
> > --- bk-current/fs/jfs/jfs_xtree.c	2003-05-31 20:30:47.000000000 -0600
> > +++ linux/fs/jfs/jfs_xtree.c	2003-05-31 21:02:14.000000000 -0600
> > @@ -4225,8 +4225,7 @@
> >   *      at the current entry at the current subtree root page
> >   *
> >   */
> > -int xtGather(t)
> > -btree_t *t;
> > +int xtGather(btree_t *t)
> >  {
> >  	int rc = 0;
> >  	xtpage_t *p;
> > 
> > I haven't yet sent that to the maintainer (worked until late last night
> > and still getting -ENOTENOUGHCOFFEE from brain).  
> > 
> > Anyway, I agree that more traditional styles should be used unless
> > otherwise indicated, but having the return type on the same line as the
> > function name is something I've warmed up to.  
> 
> OK, whatever.  But are you planning on trying to reformat the kernel and
> get that pushed into the mainline?  That's a fool's errand for lots of 
> reasons.  Nobody is going to get excited about having to look through 
> tons of patches which are all white space changes.  And it screws up
> the revision history.  Annotated listings and being able to go from that
> to the patch are a nice thing.  If you get all this stuff applied you 
> are hiding the real authorship of each of these function declarations.

Nope.  I'm just doing the absolute minimum.  Others have suggested using
Lindent and friends, but that would result in the undesirable
side-effects you've pointed out, and for little or no gain.  So, I for
one, will _not_ be doing that.

Obfuscating real authorship is a definite problem however.  But I'm
confident that you and your Bitkeeper elves can come up with a good
solution to this.  Surely this problem must slop over into other areas.

Steven