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: List-Subscribe: List-Archive: List-Post: List-Help: , 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: References: From: Kenton Varda Date: Mon, 29 Dec 2014 12:48:15 -0800 Message-ID: Subject: Re: bug: struct cmsghdr does not match system on cygwin64 To: cygwin , marco DOT atzeri AT gmail DOT com Content-Type: text/plain; charset=UTF-8 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 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