BinarySerializer Why classes that are not byte-aligned remaining bits are dropped?

Why classes that are not byte-aligned their remaining bits are dropped? There are situations where some class are not byte-aligned by nature. This is not the case before version 8.3.1. After comparing codes, I found this is introduced in #122

Feb 17 '20 13:02 zhanghaocars

They shouldn't be dropped unless they can't be preserved because the object is on some sort of boundary (like a CRC calculation or similar). Can you give me an example?

Mar 22 '20 15:03 jefffhaynes

public class HeaderClass
    {
        [FieldOrder(1)]
        [FieldBitLength(1)]
        public byte ITEM1 { get; set; }

        [FieldOrder(2)]
        [FieldBitLength(7)]
        public byte ITEM2 { get; set; }

        [FieldOrder(3)]
        [FieldBitLength(1)]
        public byte ITEM3 { get; set; }

        [FieldOrder(4)]
        [FieldBitLength(3)]
        public byte ITEM4 { get; set; }

    }
	
	public class ProtocolClass
    {
        [FieldOrder(1)]
        public HeaderClass Header { get; set; }

        [FieldOrder(2)]
        [FieldBitLength(4)]
        public byte Body { get; set; }

    }

When Deserializing ProtocolClass, the HeaderClass is truncated from 12 bits to 1byte, the tailing 4 bits are dropped.

Mar 24 '20 14:03 zhanghaocars

Ah, sure enough

Mar 24 '20 14:03 jefffhaynes

Wait, nope, this works for me. Can you post which values you're using? Maybe post the actual test you're running.

Mar 24 '20 15:03 jefffhaynes

        public class HeaderClass
        {
            [FieldOrder(1)]
            [FieldBitLength(1)]
            public byte ITEM1 { get; set; }

            [FieldOrder(2)]
            [FieldBitLength(7)]
            public byte ITEM2 { get; set; }

            [FieldOrder(3)]
            [FieldBitLength(1)]
            public byte ITEM3 { get; set; }

            [FieldOrder(4)]
            [FieldBitLength(3)]
            public byte ITEM4 { get; set; }

        }

        public class ProtocolClass
        {
            [FieldOrder(1)]
            public HeaderClass Header { get; set; }

            [FieldOrder(2)]
            [FieldBitLength(4)]
            public byte Body { get; set; }

        }

        [TestMethod()]
        public void ProtocolClassTest()
        {
            var bytes = StringConverter.StringToByteArray(
                "FF F0 ");
            BinarySerializer serializer = new BinarySerializer();
            serializer.Endianness = Endianness.Little;
            var protocol = serializer.Deserialize<ProtocolClass>(bytes);
            Assert.AreEqual(protocol.Header.ITEM1, 0x01);
            Assert.AreEqual(protocol.Header.ITEM2, 0x7f);
            Assert.AreEqual(protocol.Header.ITEM3, 0x01);
            Assert.AreEqual(protocol.Header.ITEM4, 0x07);
        }

Mar 28 '20 08:03 zhanghaocars

I don't believe the bits are being dropped but I think the byte array should be FF 0F, no?

Mar 28 '20 15:03 jefffhaynes

It should be FFF0.And this test pass in 8.3.1 and failed in 8.4.1

Mar 31 '20 09:03 zhanghaocars

Yeah, 8.4.1 was actually a breaking change and switched bit ordering to c-style ordering. Sorry about that. I believe the behavior is correct with the updated bit ordering and I think it's better to match the c convention for memory ordering since that's what people are used to with this sort of packing stuff.

Apr 07 '20 14:04 jefffhaynes

Anyway, that's how I use BinarySerializer in my work area for 2 years, almost 20 thoundard lines of BinarySerializer style code. Could you add a switch for the bit ordering, please?

Apr 20 '20 05:04 zhanghaocars

Sure, I can look into that

Apr 20 '20 13:04 jefffhaynes

Anyway, that's how I use BinarySerializer in my work area for 2 years, almost 20 thoundard lines of BinarySerializer style code. Could you add a switch for the bit ordering, please?

@zhanghaocars I think a recent PR that I did that got merged might have addressed this for you, could you perhaps confirm? https://github.com/jefffhaynes/BinarySerializer/pull/207

May 20 '23 13:05 bevanweiss