Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams This seems like a false alarm to me. Compiler doesn't seem to be sophisticated enough to see that this special case is fine. I would suggest that you just disable the warning, and restore it after you are done. user694733 Aug 23, 2018 at 6:36 Well, the protability is kind of out already with the pack . If you want serialization portably, then it's better to avoid structs altogether. Convert each member manually to byte array or back using bitshifts. That will also sort out the endianness issues. user694733 Aug 24, 2018 at 6:37

Personally I would switch off the warning for this section of code using pragmas like in the example below.

char *g(void)
#pragma diag_suppress=Pa039
  return (char *)(&d.b);
#pragma diag_default=Pa039

If this is not an option, it is possible to find the offset of b in my_t and add this to the address of d

char *f(void)
  return (char *)&d + offsetof(my_t, b);
                I think offsetof is an actual macro. If so then it will generate the warning too. I started down that rabbit hole but I needed typeof() and portability became an issue.
– William J Bagshaw
                Aug 23, 2018 at 10:25
                Unfortunately I need it to be portable too so I would want to wrap the pragmas and I end up with six in total.
– William J Bagshaw
                Aug 23, 2018 at 10:26
                @WilliamJBagshaw Since offsetof is intended for precisely this kind of things it uses internal tricks in the compiler to avoid the warning. Both of my examples gives a clean compile in iccarm 8.30.
– Johan
                Aug 23, 2018 at 10:30
                @WilliamJBagshaw The offsetof version also compiles clean in gcc (Arm Embedded Processors 7-2017-q4-major) and armclang (ARM Compiler 6.7).
– Johan
                Aug 23, 2018 at 10:35

Because a double is typically larger than an int, and because the struct is packed, the field b is not properly aligned when the smaller field appears first.

Put the larger field first and both should be properly aligned:

 typedef struct {
    double b;
    int a;
 } my_t;
                Unfortunately swapping members won't work. double will still be out of it's normal alignment due to pack. Compiler seems to take into account that my_t might be used in array, even if it's not really the case here.
– user694733
                Aug 23, 2018 at 6:34
                The main reason for using a packed structure is as a "template" to interpret data from another source. For example a communication protocol. So swapping around the order is not always an option.
– William J Bagshaw
                Aug 23, 2018 at 10:29

Firstly: you should be sure that double variable aligned inside data type by 4 bytes, your code is correct!

 #pragma pack(push, 4)
 typedef struct {
    int a;
    double b;
 } my_t;
 #pragma pack(pop)

Secondly: your variable address should be located corresponded

#pragma data_alignment = 4 
my_t d;
char * p = (char *)(&(d.b));
                This is trivial. If the field is suitably aligned for a double there will be no warning. The question is about how to avoid the warning when the field for some reason is not suitably aligned.
– Johan
                Aug 23, 2018 at 14:10
                is not trivial, is a typical mistake. Many people think that data packing and data alignment the same stuff. Keywords are ` #pragma data_alignment = 4`  You can have packed structure but this structure can be located on 0x20000001 address. For example, the compiler can use VLDR instruction to load value from structure field but this instruction must have address values are multiples of 4! So, using #pragma data_alignment = 4 will guarantee correctly located and the warning is disappeared
– denis krasutski
                Aug 23, 2018 at 15:16
        

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.