Data corruption detected when compiling for x86

[marzlevane]

Starting from v.0.8.0, the following example results in a "Data corruption detected" error when compiling as console application for net48, x86.

The compressed data is corrupted, also verified by decompressing with other implementations.

Compiling for x64 does not give an error.

Compiling for x86 while using v0.7.6 does not give an error.

using System;
using System.IO;
using ZstdSharp;

namespace ZstdConsoleTest
{
    internal class Program
    {
        static void Main(string[] args)
        {   
            string base64Input = "AAAAAAIcAAAADAAAAAgADAAIAAcACAAAAAEgAAAABwAAAENvbHVtbjEA/////4gAAAAUAAAAAAwAFgAGAAUACAAMAAwA";

            var data = new MemoryStream(Convert.FromBase64String(base64Input));

            var compressed = new MemoryStream();
            using (var compressor = new CompressionStream(compressed))
            {
                data.CopyTo(compressor);
            }

            compressed.Seek(0, SeekOrigin.Begin);

            var resultStream = new MemoryStream();
            using (var decompressionStream = new DecompressionStream(compressed))
            {
                decompressionStream.CopyTo(resultStream);
            }
        }
    }
}

ZstdSharp.ZstdException
  HResult=0x80131500
  Message=Data corruption detected
  Source=ZstdSharp
  StackTrace:
   at ZstdSharp.ThrowHelper.EnsureZstdSuccess(UIntPtr returnValue)
   at ZstdSharp.Decompressor.DecompressStream(ZSTD_inBuffer_s& input, ZSTD_outBuffer_s& output)
   at ZstdSharp.DecompressionStream.DecompressStream(ZSTD_outBuffer_s& output, Span`1 outputBuffer)
   at ZstdSharp.DecompressionStream.Read(Span`1 buffer)
   at ZstdSharp.DecompressionStream.Read(Byte[] buffer, Int32 offset, Int32 count)
   at System.IO.Stream.InternalCopyTo(Stream destination, Int32 bufferSize)
   at System.IO.Stream.CopyTo(Stream destination)

[oleg-st]

The size of the HUF_CTableHeader should depend on the architecture
Source

Fixed in 0.8.4

[oleg-st]

@marzlevane Could you check it?

[marzlevane]

With v0.8.4 compression now works as expected, thank you for the quick response.