https://github.com/jeffesp/Snappy.Sharp/blob/master/Snappy.Sharp/SnappyCompressor.cs#L296

shouldn't this be: if (s1[s1Index+matched] == s1[s2Index])

During my comparison of compression algorithms I've tested your nuget package (Snappy.Sharp 1.0.0), but something is wrong: compressing a 10MB binary file results in about 18MB output, which is quite the opposite of compression :-)

10478124 bytes => 18661217 bytes ~ 178,10%

Switching to another snappy binding (Snappy.Net if I remember correctly) results in a 64% compression ratio.

My code looks something like this:

FileInfo tmp = new FileInfo(Path.GetTempFileName());
using (FileStream fs = new FileStream(tmp.FullName, FileMode.Open, FileAccess.Write, FileShare.None))
using (SnappyStream s = new SnappyStream(fs, CompressionMode.Compress))
{
    // ... pump data into s

Could you please provide nuget pkg?

The following Code results in an Exception during decompression in Utilities.UnalignedCopy64:

byte[] uncompressed = new byte[100];
byte[] compressed = new byte[100];

Snappy.Sharp.SnappyCompressor snappyCompressor = new Snappy.Sharp.SnappyCompressor();
int countBytes = snappyCompressor.Compress( uncompressed, 0, 2, compressed, 0 );

Snappy.Sharp.SnappyDecompressor snappyDecompressor = new Snappy.Sharp.SnappyDecompressor();

// this call works
byte[] uncompressed2 = snappyDecompressor.Decompress( compressed, 0, countBytes );

// this call results in an Exception
snappyDecompressor.Decompress( compressed, 0, countBytes, uncompressed, 0, 100 );

The Exception occured with the Native-Implementation.

The loop in WriteUncomressedLength needs to be updated to: while (uncompressedLength >= bitMask)

Hi,

Thanks for making this publicaly available and porting this to C#. I had some quick questions I hope you wouldn't mind answering.

First, I didn't see a license but wanted to check that if I ported this to another open source project for some uses under the apache license, that would be okay.

Second, the readme had a lot of caveats, but glancing through the code it seems to be 32/64 bit stable, and can't see why the runtime would make much difference. Do you have any particular reason to suspect problems or was the warning there just from an abundance of caution?

Thanks for any help,
N

The native implementation does sometimes not restore the original data when compressing and then decompressing.

      byte[] uncompressed   = new byte[] { 5,0,5,0,6,0,6,0,5,0,
                                                                5,0,5,0,5,0,5,0,6,0,
                                                                   6,0,5,0,5,0,5,0,5,0,
                                   5,0,5,0,5,0,5,0,5,0,
                                   5,0,5,0,4,0,5,0,5,0,
                                   5,0,5,0,5,0,4,0,5,0,
                                   5,0,5,0,5,0,5,0,4,0,
                                   5,0,5,0,5,0,5,0,5,0,
                                   5,0};
      byte[] compressed     = new byte[100];

      Snappy.Sharp.SnappyCompressor snappyCompressor = new Snappy.Sharp.SnappyCompressor();
      int countBytes = snappyCompressor.Compress( uncompressed, 0, uncompressed.Length, compressed, 0 );






      Snappy.Sharp.SnappyDecompressor snappyDecompressor = new Snappy.Sharp.SnappyDecompressor();

      byte[] uncompressed2 = snappyDecompressor.Decompress( compressed, 0, countBytes );

The last bytes are corrupted. The compression/decompression works fine for several similar data packages but after approx. 100 packages the above data produces corrupt data.

We're seeing Compress return too-short lengths for the compressed data it has written.

This isn't an issue in the unit tests (apparently; I can't run them) because Decompress is happy to read longer than the compressedSize it has been passed. For more reliable testing, you should truncate the compressed buffer to the returned length before attempting to decompress the data:

var c = new Snappy.Sharp.SnappyCompressor();
var d = new Snappy.Sharp.SnappyDecompressor();    

var data = [ ... ]

var compressBuf = new byte[c.MaxCompressedLength(data.Length)];
var compressLen = c.Compress (data.Buffer, 0, data.Length, compressBuf);

// truncate the compressed buffer
compressBuf = compressBuf.Take (compressLen).ToArray ();

var decompressed = d.Decompress (compressBuf, 0, compressLen);
Assert.AreEqual (data, decompressed);

So I think there are two bugs here: Compress() doesn't return an accurate count of compressed bytes, and Decompress() continues to read beyond the compressLen it has been passed.

And it should be noted that this is with 7642fd8 applied, which was maybe an attempted fix for the same issue?