Closed elupus closed 1 year ago
We could add "-Wno-address-of-packed-member" to the linux config i suppose. But we probably should solve the issue.
We should fix that, what compiler and version is it? I can’t see any warnings in the CI build log, so it might be a new warning.
Gcc9
I suspect many of those structs are naturally aligned and don't actually need packing. Perhaps add a build-time assertion that the size is as expected instead, where possible?
On Mon, 7 Nov 2022 at 08:29, Joakim Plate @.***> wrote:
Gcc9
— Reply to this email directly, view it on GitHub https://github.com/OpenEtherCATsociety/SOES/issues/136#issuecomment-1305192354, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCXVIQGGYVLRJ7VEB5X6XDWHCVWLANCNFSM6AAAAAARXBUJ5Y . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Might work. Or we add anonymous unions with char for the data, so we can grab pointers to them that way. We could also avoid grabbing non char* pointers.
Possible work arounds? I've not tested on GCC 9, my VM has gcc10 and gcc 0 might have silenced it?
https://github.com/OpenEtherCATsociety/SOES/tree/fix/address_of_packed_member
Does it complain if you take address with an explicit cast to void ptr? (void*)&(coesdo->size)
Sorry, I forgot I fixed this already... See commit 097477035d768beafce5a2b4d8742a1b7bea9a29.
It was fixed by specifying the minimum alignment for the packed struct. I'm still not sure the structs actually need packing. This could probably be checked by for instance setting CCR.UNALIGN_TRP on a Cortex-M CPU.
@elupus was probably using our internal fork that is a few commits behind SOES/master.
Looks correct yes. So we can close this. Probably should update the internal one. Though im not sure how want to do to keep them in sync?
Close, fixed
By taking address of a member of a packed structure, the system might make unaligned accesses to memory which on some systems can break.