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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=e8Qq54r9fTd0tKit
	F/tcJAyFfl8HQ7VaXB6tSkRhGJI1E5M2ChyfZ2gYS0JFYW4Vjg1stkoIWsUlkUEm
	wxiCpWC/WgsFDF0KGKHph/iT/jba3Ad0Pi2I8yNLgtdjJz4jtkV+p7VTeMI9D1A+
	/W6EjlRJ9suk4YG0H28nVMuQCbg=
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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=gdjCPbr5EBPfrP3LjXKHin
	IxqvI=; b=fiO9SNQhuzwt6LBvNPDOK1DL539uXK3A0KXVtU5qaGUry2/Qfiru4O
	BA9WRc9vqneDTJd/dTSRHBzdfRaQHCjsMx42qT0xwKVxbq0b7PhmRR4k5ox7zFle
	3UKLHiaM+d/TIY2tXTP/EIMs8/fwLw18Jg1zPiLDq7/6hhc1u0kuc=
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=-1.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=existence, obliged, moss, ordinary
X-HELO:	mailout02.t-online.de
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>
From:	=?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= <HBBroeker AT t-online DOT de>
Openpgp:	preference=signencrypt
Message-ID:	<a1cb4f3e-ae07-26c2-aa7f-695f2a178961@t-online.de>
Date:	Wed, 24 Apr 2019 22:36:09 +0200
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:	<4e01e86d-83c9-5855-c4a5-29f5375dc2dc@cs.umass.edu>
X-IsSubscribed:	yes

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?  

That, like the question whether Cygwin is in any way obliged to define
it, ends up in an issue of Interpretation of Standardese.  The latter is
a language that looks deceptively much like ordinary English, but just
like Legalese, is not the same thing.

In the case at hand the point that needs interpretation is what that
parenthesis "(if supported by the protocol)" really means.  What is "the
protocol" it refers to?  What if several protocols are supported, which
differ in support for this?

The core issue, though, is: what is controlled by this "if", i.e. what
is the "then" effect?  And what's the "else"?

Cygwin's interpretation (whether by design or by accident) is: if this
never is true, the "shall define" a few lines above does not apply any
more.  If that's a correct interpretation, then source code would be
wrong to just assume presence of this macro unconditionally.  In that
case the actual problem that software noticing would be written
incorrectly (they should #ifdef MSG_EOR before using it).

An alternative interpretation could be that this entire parenthesis is
ultimately just a superfluous that adds no meaning to the standard; the
macro would have to be defined always; software would be entitled to
blindly assume its existence, and Cygwin would be wrong about this.

Either way, as Standardese goes, this is sufficiently unclear that it
IMHO calls for a defect report to the governing body of this standard.

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