<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 9:44 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On 27/08/2015 6:19 a.m., Alex Rousskov wrote:<br>
> On 08/26/2015 11:04 AM, Kinkie wrote:<br>
><br>
>> v2 patch attached.<br>
><br>
> FYI: If you have missed my last email on this thread, it is archived at<br>
> <a href="http://lists.squid-cache.org/pipermail/squid-dev/2015-August/003173.html" rel="noreferrer" target="_blank">http://lists.squid-cache.org/pipermail/squid-dev/2015-August/003173.html</a><br>
><br>
> Alex.<br>
><br>
<br>
</div></div>Also,<br>
<br>
Please double-triple-check that your new awk code works on all files its<br>
been processing so far. Some of them are in other sub-directories and<br>
IIRC the reason it was not using END already was that it sometimes had<br>
to process multiple enum types from a single file.<br></blockquote><div><br></div><div>Checked all. They are 100% identical.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
in src/neighbors.cc the range-for loop in the hunk @1607 should be a<br>
WholeEnum right?<br></blockquote><div> </div><div>Yes. Changed.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I dont see any special-case requiring ICP_END to stay in existence. All<br>
I see is it being used to check for out-of-range values being received<br>
in the packet opcode field.<br></blockquote><div><br></div><div>Already said in IRC, but reporting here for others and for the record:<br></div><div>In CachePeer.h: CachePeer.h: int counts[ICP_END+1];<br></div><div>and in neighbor.cc:neighborAlive  if ((icp_opcode) header->opcode <= ICP_END)<br><br></div><div>ICP_END is counted as a kind of "no match, for opcode" token. As you mentioned,  the report loop uses (op < ICP_END) for display so either the report loop is wrong or the counting is useless.<br><br></div><div> In which case the value ICP_END itelf should be included as an invalid<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
value; yes? or if END is an opcode why is it not being reported in the<br>
stats with enumEnd_ a value past it?<br>
<br>
Or perhapse this is simply showing the lack of an explicit isItValid()<br>
check in the API design.<br></blockquote><div><br><br></div><div>I suspect that this is the case. Not addressing it here, as it's out of scope.<br></div><div>Attaching patch in two parts: Makefile.am and everything else.<br><br><br></div><div>Thanks!<br></div></div>
</div></div>