On Wed, Jun 23, 2021 at 5:55 AM a2800276 wrote:
> As a rule if I feel that the author of libraries I intend to use are totally
> inept morons and can't be trusted to not ask me to arbitrarily call random
> unnecessary functions I would shy away from using their library altogether.
I want to
On Wed, Jun 23, 2021 at 12:55 PM a2800276 wrote:
> More practically though, most programmers would probably prefer to follow
>> guidance provided by the authors of the library they are using because by
>> virtue of having written the library, the authors probably understand not
>> only the
>
> So I think it can be safe to omit
> using gzip Reader Close in the general case.
>
In the general case it's also safe to ignore all errors, because by
definition they only occur in exceptional conditions .
More practically though, most programmers would probably prefer to follow
On Tue, Jun 22, 2021 at 4:31 PM 'Dan Kortschak' wrote:
> Yes, trivial examples also exist.
I thought one possible reason was `http#Response.Body` [1], because if
a response contains `Content-Encoding: gzip`, then Go will
automatically wrap the Body in a `gzip.Reader`. If that was the case,
then a
On Tue, 2021-06-22 at 12:45 -0500, Steven Penny wrote:
> Thanks for the help, but I found a much simpler example:
>
> https://play.golang.org/p/EcitH-85X6S
Yes, trivial examples also exist.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
On Mon, Jun 21, 2021 at 6:52 PM 'Dan Kortschak' wrote:
> https://play.golang.org/p/gwDnxVSQEM4
Thanks for the help, but I found a much simpler example:
https://play.golang.org/p/EcitH-85X6S
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
https://xkcd.com/386/
:-)
On Tuesday, 22 June 2021 at 07:19:19 UTC+1 axel.wa...@googlemail.com wrote:
> On Tue, Jun 22, 2021 at 1:23 AM Steven Penny wrote:
>
>> OK, so all all these decades of experience, why cant anyone produce a
>> small
>> program to demonstrate the problem?
>
>
> I must
On Tue, Jun 22, 2021 at 1:23 AM Steven Penny wrote:
> OK, so all all these decades of experience, why cant anyone produce a small
> program to demonstrate the problem?
I must say, I'm impressed by Dan taking the time to actually provide one.
My answer to this would have been: Because we would
On Mon, 2021-06-21 at 18:22 -0500, Steven Penny wrote:
> I am not questioning anyones knowledge, I am just asking for a
> demonstration, rather than "do it because we said so".
https://play.golang.org/p/gwDnxVSQEM4
--
You received this message because you are subscribed to the Google Groups
Thanks to all the replies, but looks like I got the answer from
another forum [1]. Copying here:
The Close() method was originally used to tear down the background
groutine used by the deflater. The background goroutine was removed
in in a June, 2011 change list [2]. The author of the CL wrote
On Mon, Jun 21, 2021 at 4:23 PM Steven Penny wrote:
>
> > You asked a question. People here are genuinely trying to help you by
> > giving you their acquired knowledge of (collectively) over more than a
> > couple of decades of Go programming.
>
> OK, so all all these decades of experience, why
On Mon, Jun 21, 2021 at 4:23 PM Steven Penny wrote:
> > You asked a question. People here are genuinely trying to help you by
> > giving you their acquired knowledge of (collectively) over more than a
> > couple of decades of Go programming.
>
> OK, so all all these decades of experience, why
But it is not "because we said so". There were actual replies that pointed
to specific issues that, in my opinion, were reason enough. To create a
specific test case that would break (assuming there is not such a test in
the standard library already. Worth checking) it would take some time for
> You asked a question. People here are genuinely trying to help you by
> giving you their acquired knowledge of (collectively) over more than a
> couple of decades of Go programming.
OK, so all all these decades of experience, why cant anyone produce a small
program to demonstrate the problem?
On Mon, 2021-06-21 at 17:57 -0500, Steven Penny wrote:
> > No, I gave a clear path that would lead to a case of a non-detected
> > error when Close is not called.
> >
> > This seems like a really odd hill to die on, but it's your choice I
> > guess.
>
> You calling "go look through 3200 lines of
Internally close calls z.decompressor.Close() where decompressor is
typically obtained via flat.NewReader(r) which states
NewReader returns a new ReadCloser that can be used to read the
uncompressed version of r. If r does not also implement io.ByteReader, the
decompressor may read more data than
> No, I gave a clear path that would lead to a case of a non-detected
> error when Close is not called.
>
> This seems like a really odd hill to die on, but it's your choice I
> guess.
You calling "go look through 3200 lines of Go code" (not including tests) [1] a
"clear path" is a dubious
On Mon, 2021-06-21 at 17:44 -0500, Steven Penny wrote:
> and none has been able to provide a simple program that demonstrate a
> problem that could arise from not closing gzip reader.
No, I gave a clear path that would lead to a case of a non-detected
error when Close is not called.
This seems
>> - https://golang.org/pkg/compress/flate
>>
>> - https://golang.org/pkg/compress/lzw
>> - https://golang.org/pkg/compress/zlib
>
> All of these do.
whoops, yeah thats true. However my original point still stands. Three people
have replied now:
- Axel Wagner
- Bruno Albuquerque
- Dan Kortschak
On Mon, 2021-06-21 at 17:30 -0500, Steven Penny wrote:
> > No other compress reader even has a Close method, so I think Im
> > fine:
>
> - https://golang.org/pkg/compress/bzip2
> - https://golang.org/pkg/compress/flate
> - https://golang.org/pkg/compress/lzw
> -
On Tue, Jun 22, 2021 at 12:31 AM Steven Penny wrote:
> No other compress reader even has a Close method, so I think Im fine:
>
> - https://golang.org/pkg/compress/bzip2
This one hasn't.
>
> - https://golang.org/pkg/compress/flate
- https://golang.org/pkg/compress/lzw
> -
Dan just pointed out that the Close() method for the gzip reader actually
does other things. If you are ok with not detecting a possible error with
deferred reporting through the Close() method then, yes, you are ok. I see
no good reason why you would though.
On Mon, Jun 21, 2021 at 3:30 PM
On Mon, Jun 21, 2021 at 11:53 PM Steven Penny wrote:
> Thanks for the responses, but I am not convinced. Other than "its just good
> practice", I havent seen a single concrete example where not closing a gzip
> reader would cause a problem.
This is what we call a black swan fallacy.
> Until
> Not to mention this all is an implementation detail and even if it did
> nothing today, relying on this behavior would be a recipe so see cobe
> breaking in the future. In this sense, the advice "if there is a Close()
> method, call it when you are done with it" is a very good one.
No other
Not to mention this all is an implementation detail and even if it did
nothing today, relying on this behavior would be a recipe so see cobe
breaking in the future. In this sense, the advice "if there is a Close()
method, call it when you are done with it" is a very good one.
On Mon, Jun 21, 2021
On Mon, 2021-06-21 at 16:53 -0500, Steven Penny wrote:
> > Again, the idiom is, if you get an `io.Closer`, `Close` should be
> > called once
> > you're done with it.
>
> Thanks for the responses, but I am not convinced. Other than "its
> just good
> practice", I havent seen a single concrete
> Again, the idiom is, if you get an `io.Closer`, `Close` should be called once
> you're done with it.
Thanks for the responses, but I am not convinced. Other than "its just good
practice", I havent seen a single concrete example where not closing a gzip
reader would cause a problem. Until that
To be clear, I said "things I could imagine". But:
On Mon, Jun 21, 2021 at 11:28 PM Steven Penny wrote:
> Thanks for the response. Couple of points:
>
> > 1. You don't get notified about checksum mismatches or the like. i.e. the
> > data you read might be corrupted and you might not realize it.
Thanks for the response. Couple of points:
> 1. You don't get notified about checksum mismatches or the like. i.e. the
> data you read might be corrupted and you might not realize it.
I dont think this is true. I tried with this file [1], and Close returns the
same error as, for example io.Copy,
There are two potential negative consequences I could imagine happening:
1. You don't get notified about checksum mismatches or the like. i.e. the
data you read might be corrupted and you might not realize it.
2. There might, theoretically, be goroutines spawned which get leaked if
you don't
If I have a program like this, it fails as expected (on Windows):
~~~
package main
import (
"fmt"
"os"
)
func main() {
old := "go1.16.5.src.tar.gz"
os.Open(old)
err := os.Rename(old, "new.tar.gz")
// The process cannot access the file because it is being used by
another
31 matches
Mail list logo
