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:reply-to:subject:to:references:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=vhMuVJD0oNB/iSBE
	Kedz+Rny11wa/eyTB8tqS0Alwc2LVMs+Qr6VKtDL0hdXmR5la6U1jjrG9P0X0KVJ
	olzGKo3NpnrnEbkYZUvyiTYX+bDHWIGRPp3lcZh1jTdD9K35U4VDcm00hAQyb139
	PiKAI2shP9mPN1uA5RU+RVOCC4E=
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:reply-to:subject:to:references:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=7ZtUGnrMkHCWVrXrleldzG
	zF448=; b=XRvhe+jxlW+fYTMvx1md2in2jMYKbrlu2N1iy9Ev7HMDlhA0VCgEeD
	JyMXCcjg7byOlntIVO7qmhOd5rwTGkU8jk5TjNkb35FBG7GVvHRABwueHlJ5lmWs
	E8JQZtwanWbD2S6ZPiAiYEGy/k8Rx5lBkRg5SvcfqGXv2VtdDZK+s=
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-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=
X-HELO: smtp-out-no.shaw.ca
Reply-To: Brian DOT Inglis AT SystematicSw DOT ab DOT ca
Subject: Re: bug: cygwin-devel v3.0.2-1 socket.h does not #define MSG_EOR per the POSIX standard
To: cygwin AT cygwin DOT com
References: <0873126E9D101A4A983DE738F4346DBC9114A8F3 AT NAWESPSCXM03V DOT nadsuswe DOT nads DOT navy DOT mil> <20190424164358 DOT GG30041 AT calimero DOT vinschen DOT de> <4e01e86d-83c9-5855-c4a5-29f5375dc2dc AT cs DOT umass DOT edu> <a1cb4f3e-ae07-26c2-aa7f-695f2a178961 AT t-online DOT de> <f73771ca-780c-cde3-2edc-08bb60b1c261 AT redhat DOT com>
From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Openpgp: preference=signencrypt
Message-ID: <3a646fc6-82cb-1980-cc85-75cd4db6f3a0@SystematicSw.ab.ca>
Date: Thu, 25 Apr 2019 09:28:36 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <f73771ca-780c-cde3-2edc-08bb60b1c261@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes

On 2019-04-24 14:50, Eric Blake wrote:
> On 4/24/19 3:36 PM, Hans-Bernhard Bröker wrote:
>> Am 24.04.2019 um 19:54 schrieb Eliot Moss:
>>> On 4/24/2019 12:43 PM, Corinna Vinschen wrote:
>>
>>>> Since MSG_EOR isn't implemented in the underlying transport layer,
>>>> there's no way to implement it in userspace.  That's why it's not
>>>> defined in Cygwin's headers.  If you have an idea how to implement
>>>> this in plain userspace, feel free to provide patches.
>>>
>>> I don't have a direct interest in this issue, but I do have a wondering.
>>> If Cygwin fails to define an error code -- even if the error cannot
>>> actually happen under Cygwin -- isn't that a problem when trying to
>>> compile imported software?  
>>
> 
> Well, MSG_EOR is not an error, but we can certainly do better than not
> defining it at all. My suggestion for the least-cost implementation:
> 
> - add a define for MSG_EOR to a non-zero value that is bitwise distinct
> from other required MSG_ values
> - return EOPNOTSUPP on attempts to use the flag in
> send()/sendmsg()/sendto() (POSIX permits that failure for protocols that
> don't support it - and none of Cygwin's protocols support it)
> - optionally, document that MSG_EOR will never be set in the results
> returned by recvmsg() (POSIX says it will only be set on protocols that
> support it - and none of Cygwin's protocols support it)
> 
> This will at least let software compile that attempts to use it, and
> hopefully that software is robust to the fact that send() may reject the
> flag and that recvmsg() cannot reliably report use of that flag.
> 
>>
>> Either way, as Standardese goes, this is sufficiently unclear that it
>> IMHO calls for a defect report to the governing body of this standard.
> 
> You're welcome to do so:
> http://austingroupbugs.net/main_page.php
> 
> although I personally thought POSIX was clear enough that MSG_EOR is
> required to be defined, even if only so that it can trigger send()
> errors showing that it is unsupported.

Would it be allowed and valid to #define MSG_EOR 0 to simplify lack of support?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

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