Update 1.x branch to 1.1.3

[Viq111]

Following up on #4

I have started working on updating it to 1.1.3 but doesn't seem straightforward as some of the methods we use are deprecated in 1.1.2:

API : zbuff : changed : prototypes now generate deprecation warnings

I haven't done a lot yet so if anyone have a PR handy that would be great, otherwise I'll try to work on it soon

[Cyan4973]

Deprecation warnings can generally be disabled at compiler level (-Wno-deprecated on gcc).
There is also a macro to disable specifically deprecation warnings generated by zbuff : ZBUFF_DISABLE_DEPRECATE_WARNINGS

[Viq111]

See #11

[Cyan4973]

Interesting,
the new streaming API was designed this way thanks to feedback from Java JNI developer which found it more convenient for bindings. My initial expectation was that if it would be convenient for Java, it would be fine too for other memory-managed languages.

The basic idea is as follows :
input / output buffers may be re-allocated / changed by the garbage collector between calls to C (but not while C code is running).
As a consequence, the pointer to beginning of the buffer must be re-initialized before each call to streaming function. Thankfully, other elements of the struct (size, pos) remain valid, so they don't need to be updated (except for application-logic operations, irrelevant to garbage collection).

Of course, one also needs the ability to guarantee that the buffer will not be moved between ptr is set and streaming method is invoked (basically, disable garbage collection for a set of buffers during a short period of time). To get such guarantee, the semantic can differ depending on language, unfortunately I'm not fluent enough in Go to tell which one.
In case a Go solution would not be easily accessible, last resort is to create an intermediate C interface to do just that : while in C mode, the garbage collector is no longer allowed to modify provided buffers.

Resetting the start buffer ptr before each invocation sounds an acceptable solution, presumably easier than moving to full manual memory management, which seems at odd with the way Go language is supposed to be used.

[Viq111]

Yes I totally understand the approach of having one struct to contain the information of the "buffer" (address, pos, size), this is in fact the same underlying implementation for Go slices (pointer, length, capacity).

The problem comes from CGo rules (https://golang.org/cmd/cgo/#hdr-Passing_pointers) that are enforced by this piece of code: https://golang.org/src/runtime/cgocheck.go
Particularly this line: C code may not keep a copy of a Go pointer after the call returns..
To comply with this rule, you can cast the Go pointers just for the lifetime of the C function call (so in its arguments) like so: 1d29771

The problem here stems from the fact that when creating a ZSTD_inBuffer or ZSTD_outBuffer , the same structure is used for both input (the Go ptr) and an output (pos); since we need to read the output, we need to allocate and keep alive the ZSTD_inBuffer at least for one instruction after the C call (to read the pos value) which is against CGo rules.
I think I will stay on the previous interface for at least the v1.1.x revisions, then I can prep a PR that uses C pointers to init ZSTD_inBuffer & ZSTD_outBuffer and manually clean-up on a Close or/and a finalizer