Live data from Hacker News

Deserializing Binary Data Files in Rust

adventures.michaelfbryan.com

21–23 of 23 posts

Re: Deserializing Binary Data Files in Rust

#21

> We get lucky here because the flags field is at offset 202 How does one calculate this offset based on the fields in the struct?

Just add all the sizes, and account for padding (there isn’t any here because everything other than the flags field is bytes arrays)

Re: Deserializing Binary Data Files in Rust

#22
post #6
post #3

Earlier quoted context omitted.

C structs are generally assumed to be laid out in the order defined with proper padding automatically inserted (as most platforms at best dislike unaligned accesses). Alignment information should only be necessary if you want to pack the structure or need to apply wider than standard alignment (e.g. need to align a 32 or 64b type to 128 bytes). The one possible issue is that reading padding is UB (i think). But here…

That's his point, you want to 1-align the struct to disable the padding to ensure the size of the structure is portable.

That makes no sense? There isn’t any padding, and if the bytes are not 8 bits it’ll never work anyway.

Re: Deserializing Binary Data Files in Rust

#23
post #3

Earlier quoted context omitted.

C structs are generally assumed to be laid out in the order defined with proper padding automatically inserted (as most platforms at best dislike unaligned accesses). Alignment information should only be necessary if you want to pack the structure or need to apply wider than standard alignment (e.g. need to align a 32 or 64b type to 128 bytes). The one possible issue is that reading padding is UB (i think). But here…

Wider than standard alignment can be pretty important though. Especially for usage with SIMD instructions.

Sure but that has no relevance whatsoever to the article do the objection is irrelevant.
Post reply on HN