<div dir="ltr">Hi,<div><br></div><div><div>+    uint32_t mask_size; /* mask size in bytes */</div><div>+    uint64_t capacity;       /* expected maximum for .count, not a hard limit */</div><div>+    int8_t bits_per_entry;     /* number of bits allocated for each entry from capacity */</div><div>     int count;          /* number of digested entries */</div><div>     int del_count;      /* number of deletions performed so far */</div></div><div><br></div><div>Can we sort data members by descending size? This will allow for more efficient packing in memory.</div><div>Apart from this, LGTM. +1 with the suggested change.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 9, 2016 at 2:37 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This patch converts the CacheDigest members and method parameters to use<br>
explicitly sized data types more appropriate for what details they hold.<br>
<br>
* 64-bit Digest capacity (entry count)<br>
* 32-bit Mask Size (byte count)<br>
*  8-bit Bit count per entry<br>
<br>
Due to various store_digest.cc code still relying on masks not exceeding<br>
2^31-1 worth of memory space we have to still assert that bitCount<br>
calculation does not exceed that value.<br>
<span class="HOEnZb"><font color="#888888"><br>
Amos<br>
<br>
</font></span><br>_______________________________________________<br>
squid-dev mailing list<br>
<a href="mailto:squid-dev@lists.squid-cache.org">squid-dev@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-dev" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">    Francesco</div>
</div>