Skip to content
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

archive/zip: possibly useless test #28700

Closed
ainar-g opened this issue Nov 9, 2018 · 4 comments
Closed

archive/zip: possibly useless test #28700

ainar-g opened this issue Nov 9, 2018 · 4 comments
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. FrozenDueToAge Testing An issue that has been verified to require only test changes, not just a test failure.
Milestone

Comments

@ainar-g
Copy link
Contributor

ainar-g commented Nov 9, 2018

While playing around with the new vet and its nilness check, I have found an interesting bug. In src/archive/zip/reader_test.go:985 we have a test for #10956, but the test doesn't actually check anything:

_, err := NewReader(bytes.NewReader(data), int64(len(data)))
// …
if err == nil && !strings.Contains(err.Error(), want) {
	t.Errorf("error = %v; want %q", err, want)
}

It should obviously be if err != nil && … here. But when I changed it, the test failed, because it returned ErrFormat instead of the custom Errorf'd error that was expected. I ran all of the package zip's tests with -cover and the coverage profile shows that the branch in (*Reader).init is never taken.

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 9, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.13 milestone Nov 9, 2018
@ALTree ALTree added the Testing An issue that has been verified to require only test changes, not just a test failure. label Nov 10, 2018
@adg
Copy link
Contributor

adg commented May 31, 2019

It seems that fix applied for #10956 (that I reviewed and approved) wasn't actually a fix; maybe in theory, but it was never tested in practice.

As you say, the example that @dvykov provided doesn't seem to get past the readDirectoryEnd function, so the additional check added to the init method is never reached. I sent a change.

@gopherbot
Copy link

Change https://golang.org/cl/179757 mentions this issue: archive/zip: remove unused special case

@odeke-em
Copy link
Member

odeke-em commented Jun 9, 2019

Thank you @ainar-g for the report and @adg for jumping on this and sending the fixing CL!
As per the wait-release tag added to the CL, it seems like this is punted to Go1.14. I shall update here accordingly and add the Early-In-Cycle tag too.

@odeke-em odeke-em added early-in-cycle A change that should be done early in the 3 month dev cycle. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jun 9, 2019
@odeke-em odeke-em modified the milestones: Go1.13, Go1.14 Jun 9, 2019
gopherbot pushed a commit that referenced this issue Aug 27, 2019
This removes a special case that was added to fix issue #10956, but that
was never actually effective. The code in the test case still fails to
read, so perhaps the zip64 support added in CL 6463050 inadvertently
caught this particular case.

It's possible that the original theorized bug still exists, but I'm not
convinced it was ever fixed.

Update #28700

Change-Id: I4854de616364510f64a6def30b308686563f8dbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/179757
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
tomocy pushed a commit to tomocy/go that referenced this issue Sep 1, 2019
This removes a special case that was added to fix issue golang#10956, but that
was never actually effective. The code in the test case still fails to
read, so perhaps the zip64 support added in CL 6463050 inadvertently
caught this particular case.

It's possible that the original theorized bug still exists, but I'm not
convinced it was ever fixed.

Update golang#28700

Change-Id: I4854de616364510f64a6def30b308686563f8dbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/179757
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
t4n6a1ka pushed a commit to t4n6a1ka/go that referenced this issue Sep 5, 2019
This removes a special case that was added to fix issue golang#10956, but that
was never actually effective. The code in the test case still fails to
read, so perhaps the zip64 support added in CL 6463050 inadvertently
caught this particular case.

It's possible that the original theorized bug still exists, but I'm not
convinced it was ever fixed.

Update golang#28700

Change-Id: I4854de616364510f64a6def30b308686563f8dbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/179757
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@klauspost
Copy link
Contributor

#46242 Reverts this change as the check itself was needed.

Since this issue is no longer relevant I believe it can be closed @dsnet

@ainar-g ainar-g closed this as completed Jun 4, 2021
@golang golang locked and limited conversation to collaborators Jun 4, 2022
@rsc rsc unassigned dsnet and adg Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. FrozenDueToAge Testing An issue that has been verified to require only test changes, not just a test failure.
Projects
None yet
Development

No branches or pull requests

9 participants