Byte order
xR3b0rn opened this issue · 6 comments
I am not sure, what to pass to unpack_can... functions.
Casting frame.data (the 8 bytes of the can frame) into a uint64_t causes byte order failures (power pc would interpret it different than intel). So it would be better to pass the char array, so the unpacking function have to ensure the correct byte order.
PS I also couldn't find something in your repo, where I may see how I shall use this function correctly. Fact is, the byte order gets messed up if I cast the frame.data array.
May be introduce a new dbcc flag for choosing the byte order.
I need more time to test it. But prehaps I will do a other push.
With the unpack and pack functions it's up to the caller to ensure the data is in the correct order, with the LSB(yte) stored in the lowest byte of the uint64_t, whatever the endianess of the underlying platform.
You should do the following:
uint64_t to_unpack = (data[LSB] << 0) | (data[LSB + 1] << 8) | (data[LSB + 2] << 16) | ....
When I get around to it I should write some unit tests which should show how to use the library. I think a solution is for me to write those unit tests and show how data should passed in and out of those functions. It would also allow me to see which interfaces are easier to use. The reason I chose the uint64_t is because it's a lot simpler to pass around that then a byte array, it should be treated as an opaque object by the rest of the system as it contains raw data, only the function that decodes and encodes the raw CAN data needs to know about the format of the uint64_t, and only it knows the format of the CAN frame data it's receiving.
Feel free to agree/disagree, I'm mainly just giving my reasoning.
My way of thinking is, the way I have to invoke this function shouldn't depend on the platform I am calling the function from.
If I call one of those function from a motrola byte ordered processor, I woudln't need to reorder the bytes and could simply cast the data array.
Imo. that's not very intuitive and if you write code for multiple processors this may end up in runtime checks for byte ordering,
So I think you should take a const char* and work on the data array like data[0]. You wont get any perfomance drawbacks if you work on the data array.
But the generated code doesn't depend on the byte order of the platform you are running it on? If a cast is performed on an array of bytes, then that introduces an endianess dependency (also one on alignment) - that's where the dependency on byte order comes from.
There's also nothing stopping someone putting the LSB in the last byte of an array, or the first byte, on either endianess platform. If I introduced a byte array into the interface I would have to introduce the convention that the LSB of the CAN packet is the first byte of the character array.
Yeah okay, I understand, you are right.
Should I close this?
yes