Upcoming Go 1.13 change https://golang.org/cl/161477 updates the runtime error strings for index out of range errors.

This change simply makes the comparison a bit more loose to handle both pre-1.13 and 1.13.

Upcoming Go 1.13 change https://golang.org/cl/161477 updates the runtime error strings for index out of range errors, which breaks the assumption that Decompress1X func has on it at https://github.com/rasky/go-lzo/blob/master/decompress.go#L160.

$ go version
$ go version devel +431b5c69ca Tue Apr 16 21:54:01 2019 +0000 darwin/amd64
$ go test
--- FAIL: TestDecompInlen (0.00s)
panic: runtime error: index out of range [0] with length 0 [recovered]
        panic: runtime error: index out of range [0] with length 0 [recovered]
        panic: runtime error: index out of range [0] with length 0

goroutine 20 [running]:
testing.tRunner.func1(0xc0000e8100)
        /Users/herbie/work/go113/go/src/testing/testing.go:830 +0x3a3
panic(0x115b440, 0xc00010a020)
        /Users/herbie/work/go113/go/src/runtime/panic.go:619 +0x1b2
github.com/rasky/go-lzo.Decompress1X.func1(0xc000106e70)
        /Users/herbie/work/google3-go/lzo/decompress.go:165 +0xfa
panic(0x115b440, 0xc00010a020)
        /Users/herbie/work/go113/go/src/runtime/panic.go:619 +0x1b2
github.com/rasky/go-lzo.(*reader).ReadU16(...)
        /Users/herbie/work/google3-go/lzo/decompress.go:94
github.com/rasky/go-lzo.Decompress1X(0x1199c40, 0xc0000c2040, 0x31, 0x0, 0xc0000d6090, 0xf, 0x10, 0x0, 0x0)
        /Users/herbie/work/google3-go/lzo/decompress.go:234 +0x944
github.com/rasky/go-lzo.TestDecompInlen(0xc0000e8100)
        /Users/herbie/work/google3-go/lzo/compress_test.go:126 +0x20c
testing.tRunner(0xc0000e8100, 0x1177800)
        /Users/herbie/work/go113/go/src/testing/testing.go:865 +0xbf
created by testing.(*T).Run
        /Users/herbie/work/go113/go/src/testing/testing.go:916 +0x350
exit status 2
FAIL    github.com/rasky/go-lzo 0.024s

I'll send a PR to update the check.

Can this project be dual licensed? perhaps in Apache 2.0 or MIT such that Apache 2.0 projects can link against this library?

Current LICENSE.gpl is too restrictive and incompatible with Apache 2.0 released projects.

Hi Giovanni,

I have a Python application that compresses data using python-lzo and then decompresses when needed in another part of application.

I'm currently porting decompressing part of the application to golang and for some reason when I'm trying to use your library it always throws LookBehindUnderrun error at me. Here is the code I'm using:

import (
    "bytes"
    "fmt"

    "github.com/rasky/go-lzo"
)

outData, err = lzo.Decompress1X(bytes.NewReader(inData), 0, 0)
if err != nil {
    fmt.Println(err)
}

Any ideas ?

Thanks in advance.

Hello,

I just ran go-fuzz on the decompressor and it found this possibly triggering an infinite loop:

https://github.com/pmezard/go-lzo/blob/fuzz-it/crashers/5ba93c9db0cff93f52b521d7420e43f6eda2784f

with the fuzzer here:

https://github.com/pmezard/go-lzo/blob/fuzz-it/fuzz.go

(I committed the corpus/ to the branch as well if you are interested).

I do not know if you implemented it just as an experiment or if you care about such reports.

Hi, I am using go language. And i want to compress files which are retrieved by ls command. I want to use rasky/go-lzo package. please guide me how can i do this?

Make existing decompress tests a bit more idiomatic by having them check returned error values.

Add two tests which compare uncompressed and compressed output from lzop(1).

Currently, we can now uncompress data compressed with lzop -1.

Make debug prints conditioned on a variable (Verbose), not commented out, and expose both Verbose and the print function (Debug) so users of this package can set them. Debug defaults to an empty function.

For the loops where we do not want to continually call an empty function, Verbose is used to control whether we call Debug at all.

Still kind of a WIP, comments appreciated. I actually have a need for this package in u-root.

Signed-off-by: Ronald G Minnich [email protected]