[squid-dev] [PATCH] Coverity(-inspired) fixes part four, HttpHeader refactor

[Alex Rousskov]

On 08/21/2015 10:47 AM, Kinkie wrote:

> This is in fact what I have tried to - sometimes not to the letter,
> unfortunately, and I'm sorry for that.

FWIW, the attached quick-and-dirty find-bad-changes.pl script detects
some offending patch changes, but it is not 100% accurate and is not
meant to replace a human developer examining the patch before posting.

Please note that the script outputs a weird combination of source code
file name and patch file line number as a GCC-style red flag line
address. This should probably be changed to use the patch file name
(while providing the source code file name elsewhere).

For your particular patch, the script raises only 6 red flags. Here are
_unaudited_ results for a few recently posted patches:

> mempools-nozero-v2.patch: red flags: 22
> PackableStream_mk5.patch: red flags: 3
> PayloadFormatter_mk3-2.patch: red flags: 0
> SQUID-99-truncate-aborted-resp-bodies-t6-1.patch: red flags: 0
> coverity-fixes-4-v2.patch: red flags: 6


HTH,

Alex.


> On Fri, Aug 21, 2015 at 6:46 PM, Alex Rousskov
> <rousskov at measurement-factory.com
> <mailto:rousskov at measurement-factory.com>> wrote:
> 
>     On 08/21/2015 04:37 AM, Kinkie wrote:
>     > I changed that only when something in the vicinity changed so not to
>     > make the patch any more enormous. I can blanket change if that's preferred.
> 
>     IMO, the rule ought to be very simple and precise: Rename NULL if and
>     only if renaming does not add any new lines to the diff.
> 
>     Same for removing HERE. Why it is so hard to follow that rule and avoid
>     unnecessary changes is really beyond me.
> 
>     Alex.
> 
> 
> 
> 
> -- 
>     Francesco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: find-bad-changes.pl
Type: application/x-perl
Size: 4385 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20150821/dc0137b3/attachment.bin>