This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Is this an incorrect Qualcomm usage or a glibc bug?
- From: Florian Weimer <fweimer at redhat dot com>
- To: honan li <sayibobo at gmail dot com>, libc-help at sourceware dot org
- Date: Fri, 1 Sep 2017 11:00:06 +0200
- Subject: Re: Is this an incorrect Qualcomm usage or a glibc bug?
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 08C8261480
- References: <CA+xL5a_qD-Pca+_86UPQV2OTdy03UqVD6h=rXVmqbjS73m5TSQ@mail.gmail.com>
On 09/01/2017 10:34 AM, honan li wrote:
> 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
Please quote actual source doe. The above snippet seems to have been
garbled.
> Is Qualcomm's usage of typecast wrong, or the usage is reasonable but
> glibc missed to consider this scenario?
Access to __ struct members is generally invalid. Based on the
information you posted, I still think the glibc change was technically
valid.
Maybe we should rename the fields to reflect their changed offsets, so
that applications which access these __ members run into compiler errors
when being recompiled, instead of silent miscompilation.
Thanks,
Florian