This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Is this an incorrect Qualcomm usage or a glibc bug?


HI,

https://patchwork.sourceware.org/patch/12453/
This modification swapped __ss_align and __ss_padding in struct
sockaddr_storage. The Qualcomm platform I'm now developing on has lots
of typecast as follows.

struct sockaddr_storage prefix_addr //IPV6 address is stored in
prefix_addr.__ss_padding
(struct sockaddr_in6 *)&(prefix_addr)->sin6_addr.s6_addr



On our ARM Cortex-A7 platform, struct alignment are as follows:

Before glibc2.23:

struct sockaddr_in6
{
    sin6_family;   //0th byte
    sin6_port;     //2nd byte
    sin6_flowinfo; //4th byte
    sin6_addr;     //8th byte
    ...
};


struct sockaddr_storage
{
    ss_family;    //0th byte
    __ss_align;   //4th byte
    __ss_padding; //8th byte
};
After glibc2.23:

struct sockaddr_storage
{
    ss_family;    //0th byte
    __ss_padding; //2nd byte
    __ss_align;   //124th byte
};
glibc changed struct sockaddr_storage, but struct sockaddr_in6 is not
changed, so this modification would cause many alignment issues on our
platform, which lead getting IPV6 addresses errors.

Is Qualcomm's usage of typecast wrong, or the usage is reasonable but
glibc missed to consider this scenario?



Thanks,

Honan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]