On 05.02.21 09:27, Patrick Menschel wrote:
Am 04.02.21 um 21:14 schrieb Oliver Hartkopp:
struct can_frames[0] is used in this struct definition to point out,
that this struct is followed by a number (0..257) struct can_frame's.
This creates a padding at the end of struct bcm_head, so that the struct
can_frame (which is always 64 bit aligned) can be directly concatenated.
so this behavior is caused by this alignment
struct can_frame {
...
__u8 data[8] __attribute__((aligned(8)));
}
and walks back upwards to
nframes (end at 36 bytes)
...
< 4 bytes gap >
...
frames (start at 40 bytes)
Should the alignment not be defined on structure instead?
struct can_frame __attribute__((aligned(8))) {
...
}
Hm, the original idea was to be able to access the data[] with a 64 bit
aligned access, e.g. to initialize the content by a single assignment.
The can_id and the other stuff (len, flags, padding, whatever) before
the data[] section is intentionally also 64 bit long.
So it should be no difference in functionality.
Interesting to know, apparently native alignment is 8 on X86_64 linux
and 4 on armhf linux. That's why it worked on X86_64.
Regarding python ctypes module, setting _pack_=8 has no remedy effect on
armhf platform, so I'll move to struct module.
Regards,
Oliver
