search

MiloszKrajewski / K4os.Compression.LZ4

LZ4/LH4HC compression for .NET Standard 1.6/2.0 (formerly known as lz4net)
MIT License
672 stars 76 forks source link

The `int LZ4Frame#Encode` overloads don't close the frame #96

Closed MeFisto94 closed 6 months ago

MeFisto94 commented 6 months ago

Description Foreword: Maybe I just didn't understand things right, so this is only my suspicion, but: I had problems when using the Encode overloads that immediately return the written bytes as they had only been returning 7. After a while, I found out that this is the header, and that one is supposed to close the frame/dispose the writer before examinating the written bytes.

After I converted my code to return a FrameWriter and properly CloseFrameing it before accessing the CompressedLength, I get the result that I desired, but I have the suspicion / observation, that said overloads don't explicitly CloseFrame, instead they use using blocks, so certainly even accessing the written bytes before disposal.

To reproduce Use the int/one shot overloads such as LZ4Frame.Encode(new byte[100], new byte[1000])

Expected behavior A reasonable return value.

Actual behavior The method is always returning 7

Environment

MiloszKrajewski commented 6 months ago

I think you are right, and it shows how important test coverage is. Whole family of methods is missing CloseFrame, for example here: https://github.com/MiloszKrajewski/K4os.Compression.LZ4/blob/52f43450287e0626276e72ac9cb483dca73bfeac/src/K4os.Compression.LZ4.Streams/LZ4Frame.encode.cs#L126

Unfortunately, I'm a little bit busy this week, but I will try to squeeze it somewhere.

MiloszKrajewski commented 6 months ago

Released in 1.3.8