> On 2/20/18 1:06 PM, Frank Filz wrote: > >> As I'm trying to update nfs41.h, I've run into the problem that the > >> commit > > check > >> is complaining that the pointer '*' on parameters is sometimes " * v" > >> and > > others > >> " *v" -- usually the same function definition. > >> > >> Presumably the generator made these. They are cosmetic. > >> > >> Why oh why are we checking this now, after all these years? > >> > >> Do I need to make a pass fixing all these header files before doing > >> real > > coding? > >> > >> Or can we turn off this silly cosmetic check? > > > > The problem is that checkpatch gets confused between multiplication > > and pointer. Shame on C for overloading *... > > > > The problem is that checkpatch doesn't recognize, for example, SVCXPRT > > as a type, so it thinks SVCXPRT *xprt is a multiplication rather than > > a declaration. > > > > The number of places this causes problems is tiny (and mostly confined > > to nfsv41.h and nfs23.h) that I have just decided to live with SVCXPRT * > > xprt. > > > Well, I cannot, because it won't let me commit anything in those files.
There's a -n or --no-verify option that will bypass the commit hooks. I suggest trying to commit without that first to make sure the only checkpatch errors/warnings are for the spacing around * and then commit again with -n to bypass checkpatch to actually commit. > > I suppose now that it seems to complain either way, we can fix them > > all to not have the space, and just force the commit and ignore the > > checkpatch warnings (when I see ONLY warnings for things I know we > > can't/won't fix in gerrithub, I ignore them and merge anyway). I'm not > > sure how much of a potential merge headache changing them all would > > cause though. I don't think nfsv41.h gets changed all that much so > > even if we had to backport something, the potential manual merge wouldn't > be awful. > > > New -dev cycle, so it's time. Yes, this is the right time to do it. > > [...] > I sympathize with your grumbling about this one... I've chosen > > the set of checkpatch checks to enable based on what seems to work > > best for our code and keeps us as consistent style as possible. I > > realize some folks have preferences opposite some of the checks, but > > our code style is now what it is... > > > Or not, as in this case. > > Anyway, I'll try to push a patch for those 2 files by tomorrow. Ok, thanks Frank ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
