-
Notifications
You must be signed in to change notification settings - Fork 18k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compress/flate: cleanup huffman_bit_writer.go #18458
Labels
Milestone
Comments
More active members of the Go team might correct me, but my guess is it's okay to remove. Note: I have not touched the Go stdlib for years. |
This makes me wonder whether we can add a special
mode to cmd/cover to track coverage (usage) of such
data tables.
I have encountered quite some cases where I want to
see if my tests forced the code to use all the entries of
a map or an array/slice, and each time I wrote ad-hoc
and case-specific code. It will be very cool if there are
some standard tool that could help with this task.
Of course, the hard part is knowing which variables to
track and figure out the story for dynamically generated
objects.
|
@minux, that would be a very useful feature, but I agree with the hard parts that you pointed out. Want to file separate issue for that? |
Deleting LGTM. |
Change https://golang.org/cl/60490 mentions this issue: |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
The
huffman_bit_writer.go
file contains references to some "extended window" implementation, which seems to provide the ability to reference a distance greater than 15 bits (up to 22 bits it seems). This goes contrary to RFC 1951, which distinctly says the maximum distance is 32768. As far as I can tell, this behavior is disabled sincelogWindowSize = 15
, which ensures that we will never use a distance greater than this. Even if it were somehow usable, we should fix this since that means we could accidentally produce non-RFC1951 compliant files.This logic has been included since 2009, so I am unsure as to what the original purpose of this is. Can we delete these?
\cc @nigeltao @krasin2
The text was updated successfully, but these errors were encountered: