| |
| ▲ | mrbadguy 7 months ago | parent [-] | | Can you please give me an example of what you don’t like? I’m not sure I understand the “write the code manually to do a struct” bit. You have to define the struct for sure, but beyond that you just pass it to binary.Read and it comes back with the fields populated. I don’t see how you’d avoid defining the struct. | | |
| ▲ | dfawcus 7 months ago | parent [-] | | I believe what he wants, is the usual C trick of defining a struct which represents the wire format (with all the usual caveats). Then cast a char pointer to be an instance of a pointer to that struct. Sort of like this: https://github.com/danos/vyatta-dataplane/blob/master/src/ecmp.c#L108-L116
It sort of works on x86 chips, but is not so effective on MIPS, PPC, etc where misaligned access are either unavailable, or slow, or even trap and are slower still.Once one has to handle that sort of situation, and actually copy the data, the lack of language support for such type-punning becomes immaterial. | | |
| ▲ | mrbadguy 7 months ago | parent | next [-] | | Oh I see, thanks for the clarification! Personally, I'm fine without that and with something like func Foo(r io.Reader) {
var m MyStruct
binary.Read(r, binary.LittleEndian, &m)
}
but we may be operating in different contexts where the underlying copy is or isn't a problem. That said, depending on the implementation of the reader passed in, the bytes might be being streamed from elsewhere, in which case the copying is minimised. | |
| ▲ | guappa 7 months ago | parent | prev [-] | | https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.ht... If the misaligned access is slow… it will be slow whether the compiler reads the variable or if you hand-write even slower and error prone code. That said, please show me a protocol that generates unaligned accesses on any architecture. People writing protocols aren't noobs :) |
|
|
|
