Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Read 3 bytes with a uint and advance only those 3 bytes on the stream #186

Open
sn4k3 opened this issue May 24, 2022 · 7 comments
Assignees
Labels

Comments

@sn4k3
Copy link

sn4k3 commented May 24, 2022

I have some situations where the format have uint's with 3 bytes, currently is it possible to define an uint and deserialize/serialize in 3 byte order? Making stream only to advance that 3 bytes so the next field will decode/encode at position 3 rather than 4?

PS: Should be cool to enable github discussions to use it as a forum board for questions instead the need to use issues for that purpose

@sn4k3
Copy link
Author

sn4k3 commented Jul 23, 2022

Still struggle with this one... [FieldBitLength(24)] uint FieldName {get; set;} does not return the correct value from 3 bytes as uint. Any suggestion?

@jefffhaynes
Copy link
Owner

Can you give me some more info? I just wrote a simple test that seems to work but I might be missing something.

@sn4k3
Copy link
Author

sn4k3 commented Jul 23, 2022

Sure, here my definition:

devenv_2022-07-23_23-58-18

What i get:

devenv_2022-07-24_00-03-48

What i expect:

010Editor_2022-07-24_00-04-18

File is in BIG order and use a ton of uint24

@jefffhaynes
Copy link
Owner

Ahh it's big endian. Unfortunately there is a bug involving big endian and bit fields. I've spent hours trying to fix it but unfortunately it's incredibly complex. I need to at least add a check that will throw in these cases. Sorry about that, I'll try to get back to it soon!

@sn4k3
Copy link
Author

sn4k3 commented Jul 24, 2022

Thanks for looking into it.
I've not look at source code, but one thing i always do when working with bytes and convertion is to avoid C# converter functions (BitConverter), and do my own with bitwise. Those utility methods can return different outputs depending on machine endiness, unless you cover it with if (BitConverter.IsLittleEndian) Array.Reverse(bytes); which is easy forgetable.

@jefffhaynes
Copy link
Owner

As much as I would like to blame something else, it is unfortunately all my own code! The issue has to do with assumptions I made when doing bit-packing early on. Unfortunately, fixing it will mean rewriting quite a bit of the underlying bit field assemblage, which gets complicated fast. If you're interested, most of the rabbit hole is contained in BoundedStream.

@jefffhaynes jefffhaynes self-assigned this Dec 24, 2022
@bevanweiss
Copy link
Contributor

@sn4k3 could you perhaps but together a couple of Test Cases for this in Github (within the FieldBitOffset / Endianess stuff probably makes sense).

I've had a bit of a dig through the BoundedStream stuff recently, so might be able to have a look at this problem also.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants