X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=Co1ABZ7
	b1tNDzJlr8SCFQB5VShlAox24/Xml1pZ3fb5yd5NRYy8cba29aZw0XDZmXDXn5nA
	lkw8Paygob8QxHGbHkfKE0CiyXg+ood9K8D5snoXOeFh1hXt3DrP0ZhX6IHsYHyD
	bJxZ5h0JQCNr1o3bc2BbX3RUOD9XW/tWyrpU=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=Vm4tcnEN63LT9
	HgHWrDZDq4OWUY=; b=UI7datNHbunrxbVz0vuYlm9EZDXiyu2ecX1n+vPLT1LCC
	P5UQv/lo16XIZ1GyBJdn193m73xPylSc9CLuMQYF3+gWF2ogRLZGrZnZvlocJ6k5
	CAZm8cJMBNKwMQB/Y6vFJPCqNwf46TglHxnIaP8Jc7ae17ng/h/gSUd8lsfrmE=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2
X-HELO:	mail-la0-f47.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=YtSfNXSVOd+0sedAeZOJK8TTA1HVlv+O/ZccitDREus=; b=CXIZdgbpKtXWBivTS9oGkDV2B6/kIs3XM8QGh9RPdySibwKwMy2BripPtcg+vaNTvv 5yZ7bkt8fntwkWW7JZ1PsQanLcJS+/tHNt5uHeWNA/1KTxwDnmWrIasiUwp1viwjmYbu D4vwz0z8X2zgmcAmTfM6FdzXlhHcM4/N22smsH/MEmwHhZKnGDoZQDrIbUuR5FRZ5m/1 uqBnyzJ/5+zMDdpyjX0C6gukm0D03U5XhI+yKOqfcW/Zk+rV+/efyWYIddiK00Ast7DT hddronFmGunyKkpJsWkt4dS1XEYsqNrMlhvpOokdgMH+m0cwHAOd0NVQftVxA1e3BnQJ wjog==
X-Gm-Message-State:	ALoCoQlVbiX5tBmwdwimuelKjXRDF9b5ZyOMTIp684vLOjk1Vd2Zypu1DDvn8mi+WNJNrRtFjICq
X-Received:	by 10.152.219.3 with SMTP id pk3mr58906722lac.19.1419886115365; Mon, 29 Dec 2014 12:48:35 -0800 (PST)
MIME-Version:	1.0
In-Reply-To:	<CAOP=4wh3i=gHtCTPwksmrP=3_aQTMiFw8_0Vg08hrCPg53m8fg@mail.gmail.com>
References:	<CAOP=4wh3i=gHtCTPwksmrP=3_aQTMiFw8_0Vg08hrCPg53m8fg AT mail DOT gmail DOT com>
From:	Kenton Varda <kenton AT sandstorm DOT io>
Date:	Mon, 29 Dec 2014 12:48:15 -0800
Message-ID:	<CAOP=4whbdcjsaSVzEbvvLhFhE5v210Y8CoXV+JGboank=mKsOw@mail.gmail.com>
Subject:	Re: bug: struct cmsghdr does not match system on cygwin64
To:	cygwin <cygwin AT cygwin DOT com>, marco DOT atzeri AT gmail DOT com

Marco Atzeri wrote:
> If I am not wrong, for 64bit,
> on windows sizeof (SIZE_T) =4
> while on cygwin sizeof(size_t)=8

sizeof(SIZE_T) == 8 on Win64. The purpose of SIZE_T is to be the same
size as a pointer:
  http://msdn.microsoft.com/en-us/library/cc441980.aspx

To be clear, I am actually observing everything after cmsg_len being
shifted 4 bytes in real code that works on other platforms.
Specifically, the Cap'n Proto unit tests fail on Cygwin but pass on
Linux and OSX after this commit:
  https://github.com/kentonv/capnproto/commit/68ad32202ed43e42a15de3da90a86b7efdcf8f12

-Kenton

On Sun, Dec 28, 2014 at 9:03 PM, Kenton Varda <kenton AT sandstorm DOT io> wrote:
> Hello Cygwin,
>
> Cygwin defines 'struct cmsghdr' (see recvmsg(2)) as follows (cygwin/socket.h):
>
> struct cmsghdr
> {
>   socklen_t             cmsg_len;       /* Length of cmsghdr + data     */
>   int                   cmsg_level;     /* Protocol                     */
>   int                   cmsg_type;      /* Protocol type                */
> };
>
> Unfortunately, Winsock defines its equivalent type as follows (ws2def.h):
>
> typedef struct _WSACMSGHDR {
>     SIZE_T      cmsg_len;
>     INT         cmsg_level;
>     INT         cmsg_type;
>     /* followed by UCHAR cmsg_data[] */
> } WSACMSGHDR, *PWSACMSGHDR, FAR *LPWSACMSGHDR;
>
> As you can see, on a 64-bit build, the cmsg_len is 64 bits in the
> Winsock struct. However, Cygwin's socklen_t is always 32 bits,
> therefore cmsg_len is 32 bits in the Cygwin struct.
>
> Cygwin's recvmsg() calls WSARecvMsg() passing the control message
> buffer pointer verbatim, expecting the system to fill the buffer
> correctly. The system dutifully fills the buffer with control messages
> that are not legible using Cygwin's definition of the struct, leaving
> the calling application with apparent garbage data.
>
> sendmsg() likely has a similar problem, though I haven't checked.
>
> It seems like the best solution is to change the type of cmsg_len to
> size_t. While this would technically violate standards (I think?), it
> turns out the Linux headers define it this way, so presumably no one
> will mind.
>
> The other option is to perform some sort of translation of the control
> message buffer inside sendmsg() and recvmsg(), but that would
> obviously be painful and error-prone.
>
> AFAICT, this bug breaks all users of the IP_PKTINFO and IPV6_PKTINFO
> socket options on cygwin64.
>
> -Kenton

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -