That was my conclusion as well, so I filed an issued about it

Fortunately, BZ2_bzCompressEnd does not make use of the stored outbuf since
all output data will be drained via calls to BZ2_bzCompress.

On Wednesday, November 18, 2015 at 6:53:43 PM UTC-8, David Crawshaw wrote:

On Wed, Nov 18, 2015 at 8:35 PM, Ian Lance Taylor <ia...@golang.org
<javascript:>> wrote:
On Wed, Nov 18, 2015 at 11:29 AM, <thebroke...@gmail.com <javascript:>>
Then doesn't that mean that the bzip2 example from GOPL is also wrong?
does both:

stores a Go pointer (in Go) in a C struct (in C)
and then pass a pointer to that struct to C code (in C).
I don't have a copy of the book, so I don't know.
The example is https://github.com/adonovan/gopl.io/tree/master/ch13/bzip

I believe the code does not follow the new rules for a slightly
different reason: the C code stores a Go pointer in Go memory. (The
type is *C.bz_stream, but it is allocated on the Go heap.) So there's
a missing write barrier.

Correcting it would require allocating bz_stream using malloc and
making sure the Go pointers don't live in the C struct for any longer
than the duration of the call to C.bz2compress. The tricky part is
BZ2_bzCompressEnd. If that function makes use of the stored outbuf
pointer, then it needs to be called from a new C function that is
explicitly passed the outbuf pointer.

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 6 | next ›
Discussion Overview
groupgolang-nuts @
postedNov 18, '15 at 8:13a
activeNov 19, '15 at 3:03a



site design / logo © 2021 Grokbase