Re: [PATCH] Removed unnecessary void* from hashmap.h that caused compile warnings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/15, Randall S. Becker wrote:
> On January 15, 2018 3:43 PM, Thomas Gummerer wrote:
> > Thanks for your patch!  A few nitpicks below:
> > 
> > > Subject: [PATCH] Removed unnecessary void* from hashmap.h that caused
> > > compile warnings
> > 
> > From Documentation/SubmittingPatches:
> > 
> >     Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
> >     instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
> >     to do frotz", as if you are giving orders to the codebase to change
> >     its behavior.
> > 
> > I liked the subject Philip suggested in the other thread: "hashmap.h:
> > remove unnecessary void*", or maybe "hashmap.h: remove unnecessary
> > variable".
> > 
> > On 01/14, randall.s.becker@xxxxxxxxxx wrote:
> > > From: "Randall S. Becker" <rsbecker@xxxxxxxxxxxxx>
> > >
> > > * hashmap.h: Revised the while loop in the
> > hashmap_enable_item_counting
> > > 	to remove unneeded void* item.
> > 
> > As above, this should be described in an imperative mood, and describe why
> > this is a good change and should be merged.  Maybe something along the
> > lines of the below?
> > 
> >     In 'hashmap_enable_item_counting()', item is assigned but never
> >     used.  This causes a warning on HP NonStop.  As the variable is
> >     never used, fix this by just removing it.
> > 
> > > Signed-off-by: Randall S. Becker <rsbecker@xxxxxxxxxxxxx>
> > >
> > > [..snip..]
> > >
> I like it. Do you need this resubmitted? Or should I just learn for next
> time?

I think it would be good if you resubmit the patch.  These rules tend
to be applied quite strictly, as you can also see when looking at the
git commit history.  So with the updated commit message Junio should
just be able to pick it up (unless there's something I missed here as
well :))

As a side note, I just noticed the two submissions both had [PATCH] in
the title, whereas new submissions should be marked as such using
[PATCH v2] etc. as prefix, so it's easier for reviewers to know which
version is the newer one.

> Cheers,
> Randall
> 



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux