Nix HpackVarintDecoder::Max{ExtensionBytes,Offset}
The motivation is to prepare HpackVarintDecoder to conditionally support 62 bit integers as required by the QPACK specs. This will of course have to be flag protected. HpackVarintDecoder::MaxExtensionBytes() and MaxOffset() would need to return different values depending on the value of the flag. It's a lot easier to get rid of them instead. In HpackVarintDecoder::Resume(), use a locally defined const instead of MaxOffset(). In MarkDone() et al., use numeric_limits::max() instead of |MaxOffset() + 7|. This value is so large that it does not matter if HpackVarintDecoder is in up-to-28-bit-mode or up-to-62-bit-mode. Avoid using a method to cut down on clutter in release builds. In HpackVarintDecoderTest.ValueTooLarge, hardcode the large value. It does not hurt to reduce logic in tests anyway. This CL lands server change 214703557 by bnc. BUG=488484 Change-Id: Ie12bfda99b478549bcc5b126be54e51804c0d85c Reviewed-on: https://chromium-review.googlesource.com/c/1291592 Commit-Queue: Dianna Hu <diannahu@chromium.org> Reviewed-by:Ryan Hamilton <rch@chromium.org> Cr-Commit-Position: refs/heads/master@{#601269}
Showing
Please register or sign in to comment