This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Is this an incorrect Qualcomm usage or a glibc bug?
- From: honan li <sayibobo at gmail dot com>
- To: libc-help at sourceware dot org
- Date: Fri, 1 Sep 2017 16:34:34 +0800
- Subject: Is this an incorrect Qualcomm usage or a glibc bug?
- Authentication-results: sourceware.org; auth=none
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