Convert Utility.WriteLittleEndian(...) method to be safe about sharpcompress HOT 7 OPEN

This is just a little performance. I think there is an alternative method for targets that don't like unsafe.

from sharpcompress.

It seems that in my pull request I didn't take into consideration that platform can be big-endian as well, which will make BitConverter.GetBytes() to be wrong when running on such platforms (if indeed WriteLittleEndian() should write bytes using little-endian method). Can some one look into this closer maybe. From what I understand code will need to be modified like following to work properly on all platforms:

public static void WriteLittleEndian(byte[] array, int pos, short value)
{
    byte[] newBytes = BitConverter.GetBytes(value);
    if (!BitConverter.IsLittleEndian)
        Array.Reverse(newBytes);
    Array.Copy(newBytes, 0, array, pos, newBytes.Length);
}

It will most likely not affect any real code, but still better to do it right.

from sharpcompress.

I believe the algorithms using that operate in a VM of sorts. Little Endianness is expected regardless of platform.

from sharpcompress.

@haykpetros , why make it so overly complicated using BitConverter, if statements, Array.Copy and Array.Reverse? If you want to write a short value (16bit) into a byte array in little-endian with only managed/safe code, just simply do:

array[pos] = (byte) (value & 0xFF); array[pos+1] = (byte) (value >> 8);

from sharpcompress.

@elgonzo, I personally think it is more readable. There are two overrides to this method, one accepting short another accepting int. Though I don't have personally preference if you write it like in your example using casting, but I am always inclined to make code readable for everyone.

from sharpcompress.

I don't know how often this method is called, but allocating a new array (via BitConverter.GetBytes) for every number written probably is gonna hurt performance. Considering the point of the original unsafe code was performance, your suggestion sounds like a bad idea.

The suggestion of elgonzo is what one should do if unsafe code isn't allowed.

from sharpcompress.

@weltkante well, this particular suggestion wasn't about performance. Originally my suggestion was to remove conditional compilation as it wasn't necessary. I don't have objections to what @elgonzo said, but based on testing on my machine I saw no performance gains.

from sharpcompress.