[OpenAFS-devel] warnings fix

[Russ Allbery]

Marcus Watts <mdw@umich.edu> writes:

> I promised last week to post a warnings patch.  Apparently I was too
> successful at shaming the gatekeepers, because they've since committed a
> lot of warnings fixes to git.  That means my patch is already obselete.

Or, alternately, Simon kept submitting the warning patches that he's
already been working on for some months now, somewhat faster because now
he can use Git instead of quilt, and because Gerrit rocks for code review
and Git makes this all much easier, we're now applying them at a much
faster rate.

Your explanation has a lot more interpersonal drama and would make for a
better reality TV show, though.  :)

I'm sorry that you and Simon ended up duplicating work.  We should find a
better way of coordinating cleanups so that that doesn't happen.  Also, I
strongly encourage doing cleanups in small chunks and submitting them
frequently, which Git and Gerrit makes much easier, since that reduces the
window where you have to rebase your change on subsequent commits.

> Since there's one of me and many gatekeepers, there's no point my trying
> to chase a moving target.  Presumably the most valuable thing about this
> patch today is as a bench mark - "here's what can be easily fixed".
>
> 1. patches and files

If you, or anyone else, would be willing to try applying these to the
current Git source and seeing what's left that Simon hasn't submitted
patches for, pushing the results to Gerrit, that would be great.

> Needless to say, it's a lot easier to find new problems from 200
> warnings than from 3000 warnings.  So hk34 includes additional
> improvements to rxk5/k5ssl that were simply not obvious before.

Indeed.  That's one of the reasons why we've been pushing this.

There's unfortunately a lot of work left to do, particularly with 64-bit
builds.

> des		11	16	

Some of these are due to the misfeatures in the DES API that probably
aren't worth worrying too much about, since trying to fix them tends to
break things badly.  We'll get rid of this when we have a better
encryption layer.

> Many of the interesting surprises were in the backup logic.  Apparently
> people who use "cvs head" don't use the afs backup utilities, or at
> least, don't stress it much.

That doesn't surprise me.

> I made an attempt to use more "const".  This is a bit ugly, but the
> potential win is the ability to trap modifications to data that should
> not change.

I'm a huge fan of const, so I would be happy to review changes that take
us in that direction.  I use const extensively in all of my personal code
and have had it catch a lot of bugs for me.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>