Skip to content

bogus io.EOF error when error var is predeclared #15

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

Closed
kolyshkin opened this issue Sep 9, 2021 · 5 comments
Closed

bogus io.EOF error when error var is predeclared #15

kolyshkin opened this issue Sep 9, 2021 · 5 comments
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@kolyshkin
Copy link
Contributor

I have previously submitted #12 hoping it would fix to eliminate a bogus error in my code.

Today I found it did not.

The following code is fine (i.e. no warnings):

func UseBufioReadLine(r io.Reader) error {
       rd := bufio.NewReader(r)
       for {
               _, _, err := rd.ReadLine()
               if err != nil {
                       if err == io.EOF {
                               err = nil
                       }
               }
               return err
       }
}

but if we modify it in this way:

 func UseBufioReadLine(r io.Reader) error {
        rd := bufio.NewReader(r)
+       var err error
        for {
-               _, _, err := rd.ReadLine()
+               _, _, err = rd.ReadLine()
                if err != nil {
                        if err == io.EOF {

we will have something like

func UseBufioReadLine(r io.Reader) error {
          rd := bufio.NewReader(r)
          var err error
          for {
                  _, _, err = rd.ReadLine()
                  if err != nil {
                          if err == io.EOF {
                                  err = nil
                          }
                  }
                  return err
          }
  }

and this code results in a warning:

comparing with == will fail on wrapped errors. Use errors.Is to check for a specific error

Alas, I don't know internals good enough to try to fix it.

@kolyshkin kolyshkin changed the title bogus io.EOF error bogus io.EOF error when error var is predeclared Sep 9, 2021
@kolyshkin
Copy link
Contributor Author

Similarly, for existing code in errorlint/testdata/src/allowed/allowed.go, the following change results in a warning.

@@ -113,7 +114,9 @@ type CompressedFile struct {
 }
 
 func (c CompressedFile) Read(p []byte) (int, error) {
-       n, err := c.reader.Read(p)
+       var n int
+       var err error
+       n, err = c.reader.Read(p)
        if err == io.EOF {
                return n, io.EOF
        }

@kolyshkin
Copy link
Contributor Author

Happens because callExpr in isAllowedErrorComparison is nil. This is where my debug abilities stop 🤡

@polyfloyd
Copy link
Owner

The allowed error set is implemented by checking comparisons for whether an error is returned from a known safe function.

The current implementation uses the declaration of the error variable to see whether it comes from such a function. In your case, the declaration is a variable declaration without initialisation for which no logic is implemented yet.

We can fix this by not only checking the declaration, but also the last assignment to the error variable. Checking only the last assignment also requires understanding the control flow, which would make this linter way more complex than I am able to support. So I would propose an implementation which just checks all assigning expressions instead.

Will do some hacking when I have time, unless someone beats me to it :P

@polyfloyd polyfloyd added the bug Something isn't working label Sep 10, 2021
@polyfloyd polyfloyd added the help wanted Extra attention is needed label Oct 2, 2021
@polyfloyd
Copy link
Owner

@kolyshkin I have pushed a fix to branch issue-15. Could you please test whether this solves your issue?

@polyfloyd
Copy link
Owner

I have done some more testing on my own projects and it seems to work well. Merged my changes :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants