X-Recipient: archive-cygwin@delorie.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:date
	:message-id:subject:from:to:content-type; q=dns; s=default; b=bP
	NMMFP3kPBa/mHpz43aXTx1DhGCA6xWRDPpvNnXP5P+/3uqAqzyHJ9P8FEbvRun6M
	kj0HCYzOnaL2bejZANjHDn8KnKuq6GBLMSD6F4pBxW6iUQijZohkouC3aPr0PyGY
	kJhe2tivye0Ql8lZfhb7eXc0w267sNVMnIXaLewVw=
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:date
	:message-id:subject:from:to:content-type; s=default; bh=k+ZBbrk8
	r1AUXi7YNTcKji9R2CI=; b=FbzxVzq4gp+X/1OxfwAHqLrn4ICR0WOuqN9TJTRS
	AsppgN2OvLj/+T1rckA+iUSO8XAPIGYmsIbfB8Gkd8graFjW23zMAIokFzixvcd0
	r90fXEdWkEd9CfGDl2gZBGPeilYl1BuW+U5EL4KV89mboFneZjiBdkiH9xiHZxCe
	nFw=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=publish
X-HELO: mail-vk0-f53.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:date         :message-id:subject:from:to;        bh=nY9UT3/NcL4YmqpTmfVjWDwb0lwAGpWls+AAaZ/S2wA=;        b=Swk+T8FgHkBOF4H6RKcXpDnRzj7u0WrARcq1Vah/W6hN9xmerDtCDjLZDSaGlgTc3o         YuvuHxMFL3LH90Q/iR/EgWotuzBPt6Eo9Z+gg3WjaJCLLEPC1Hloi0By3op/FVMLaSsp         nMcg5LcCIxLIcSZRBm5rLM7rGdkstQXWNXDDBXVQXtFJlXAXrX76KO1SryyASy9zfYfS         f6MfEnwclPFGlOzb15xMo0rN9jmf44rGl+NQgp+x8BOLiyUrLtsJpT2Kkd+qDbIHWG0X         i6cbl+9wjpQ13Vqa2XyFBvZIYLA1JqT50rtlzYp6siPdmNAgSbKOh/mlU3cl37ePWDyA         N09Q==
X-Gm-Message-State: AOPr4FVjUhquF4nidyninBFBI1Aa76odVXeY2YaEY8BTkQCb+xsUc/BWIn/alASu6SwjE9S/rt5q+utA9Lj10Q==
MIME-Version: 1.0
X-Received: by 10.31.167.195 with SMTP id q186mr11479365vke.113.1460753651766; Fri, 15 Apr 2016 13:54:11 -0700 (PDT)
In-Reply-To: <20160415204150.GE24565@calimero.vinschen.de>
References: <CAAkR8+sqWOntu_zZ3K_CvkVA5mjnJEM1N=GN1SzK-oFvJ3BxsA@mail.gmail.com>	<20160415192350.GD24565@calimero.vinschen.de>	<CAAkR8+uhSv8EPFJyYgt48H05O+uFqfTaVG+Fv0UH74OYinYWkQ@mail.gmail.com>	<20160415204150.GE24565@calimero.vinschen.de>
Date: Fri, 15 Apr 2016 13:54:11 -0700
Message-ID: <CAAkR8+u_qpN2mTk2_GCWSg1LVAS7EJEjcdLZBO6sepwCvdYjjQ@mail.gmail.com>
Subject: Re: Cygwin 64bits gcc produces erroneous constants with the win32 headers.
From: Nicolas Noble <pixel@nobis-crew.org>
To: cygwin@cygwin.com
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes

>> Right, but that isn't the same thing. I am well aware of the various
>> issues tied with sizeof(long),
>
> Sorry, I wasn't aware of this since you wrote something along the lines
> of gcc should make sizeof(long) == 4 which just doesn't make sense in an
> LP64 environment.

I can see how this was confusing, yes. I was trying to make the point that


> One problem is that you're not supposed to use WinSock or the winsock
> headers when compiling Cygwin applications.  Use the Cygwin POSIX headers
> and Cygwin socket functions instead.  If you use WinSock headers and/or
> functions and it breaks, you got to keep the pieces.

Okay. See, that's something I didn't see documented anywhere :-) The
documentation seems to say that it's fair game to use the Win32 API as
long as you're linking the libraries in, and no mention of what is and
isn't acceptable.

Note that I'm not talking about mixing up Cygwin sockets and WinSock
sockets. I'm simply talking about compiling a piece of code that is
100% WinSock aware, and exposes an API that doesn't even mention
sockets. Think, I don't know, libcurl in easy mode for instance. Or
maybe a "publish tweets on twitter" library. It should be acceptable
that said static code be fully independent, and usable with cygwin
code.

Of course, solutions might be to say "sorry, it doesn't actually
compile properly with Cygwin, please only use mingw-w64 to compile it,
then link the resulting static .a file with your project" or "sorry,
using Cygwin, you'll have to use the posix-version of the library,
thus having to lose some amount of performance due to the Cygwin
socket translation layer", but I find neither very appropriate. I'd
rather have the code be compatible with cygwin's compiler and
environment, while retaining the ability to fully use the WinSock API.


> However, Mingw-w64 already contains a lot of changes to accommodate
> the Cygwin LP64 environment, and incidentally there's already a type
> available which does the right thing, so it might be a good idea to
> suggest using that:
>
> #define FIONBIO _IOW('f',126,__ms_u_long)

So you're saying that the w32api-headers cygwin package actually comes
from mingw-w64 ? I can go and bug them instead then :-)

--
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

