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:references:from:to:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=FpTFaEVnOagSbw/r
	jv4NLsb0EGlt52nZ4r8P75h0Nh5SOcMg18VI+7S64Z/nUl/9jN8TyNvoNSDi5wXB
	6sERebsb9V9ex+v+1ipqlPY9TIwvYVev+U5+UjddRts9CwgU75zVHrWhi2D/TC7m
	oZ0f4N/2G1DK9z+N4By1msYP8U4=
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:references:from:to:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=EcEVtEa7HMuIjFWOzBV5Iv
	04lhI=; b=gfohYnOdFT+6KU+yzNx07xDi7WfBrayjQDSli4vM4T3NQw5/KOkJj4
	wBZroet9FwiKs3RDNcIxWb0rnjgT6GbfLclamUTPSvPRoTFXBpWdYHTPmHhglqlZ
	4gKRadinr27GiyPSxgwz85onCVr7T+ERZ7Hb6D1IRN082rGpYWIhk=
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.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=unavailable version=3.3.2 spammy=
X-HELO:	atfriesa01.ssi-schaefer.com
Subject:	Re: textmode for stdout, what is "correct" now?
References:	<20190215124844 DOT GE2702 AT calimero DOT vinschen DOT de> <6d02258d-115d-135c-1404-1b02eec34045 AT ssi-schaefer DOT com> <20190215203108 DOT GN2702 AT calimero DOT vinschen DOT de> <f1372893-842b-93e1-f0f2-3a9f3ac02e20 AT ssi-schaefer DOT com> <20190216093855 DOT GR2702 AT calimero DOT vinschen DOT de> <863f060b-9c2f-1c78-30e8-c1486d567f74 AT ssi-schaefer DOT com> <20190216174313 DOT GG4256 AT calimero DOT vinschen DOT de> <380fcd6e-cbe1-ebe4-c13f-a8d911c148ac AT ssi-schaefer DOT com> <20190218102650 DOT GW4256 AT calimero DOT vinschen DOT de> <696f5a12-ad45-c3d9-715b-bd68b3f8d14c AT ssi-schaefer DOT com> <20190218131514 DOT GX4256 AT calimero DOT vinschen DOT de>
From:	Michael Haubenwallner <michael DOT haubenwallner AT ssi-schaefer DOT com>
To:	cygwin AT cygwin DOT com
Openpgp:	preference=signencrypt
Message-ID:	<1c318746-170e-a0ba-e42f-e97199cb288f@ssi-schaefer.com>
Date:	Mon, 18 Feb 2019 15:45:21 +0100
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version:	1.0
In-Reply-To:	<20190218131514.GX4256@calimero.vinschen.de>

On 2/18/19 2:15 PM, Corinna Vinschen wrote:
> On Feb 18 12:47, Michael Haubenwallner wrote:
>> On 2/18/19 11:26 AM, Corinna Vinschen wrote:
>>> On Feb 18 10:40, Michael Haubenwallner wrote:
>>>> On 2/16/19 6:43 PM, Corinna Vinschen wrote:
>>>>> I really miss the problem you're trying to solve here.  Why should an
>>>>> application setting O_BINARY explicitely revert this decision on the
>>>>> same file descriptor?  That doesn't make sense.
>>>>
>>>> Well, it's not necessarily about really switching binary mode on and off,
>>>> it's more about avoiding breakage when applications try to intuitively
>>>> follow the original API, even if that actually causes the call to
>>>> setmode(fd, O_TEXT) to be redundant.
>>>>
>>>> OTOH, this question also would apply to native Win32 applications, so why
>>>> do people call setmode(fd, O_TEXT) with any DOS based platform at all?
>>>>
>>>> IMO, unfortunately we're not in a position to modify the intention of the
>>>> original API.  And finally, I do want to stop discussions like this one
>>>> with application developers like openssl, as soon as we can argue like:
>>>> "Cygwin does not use \r internally, but does support text mode mounts,
>>>> so we had to invent the Cygwin text mode, which may or may not use \r.
>>>> Hence you get the Cygwin text mode with O_TEXT, and if you really are
>>>> in some 'unix2dos' position, please use the new O_DOSTEXT mode instead."
>>>>
>>>> However, agreed this does not seem to be trivial to implement.  Yet I
>>>> will look into it when there is a chance for a patches to be accepted.

<<snip>>
> 
> No, wait.  This is getting a bit out of hand.  The fact that we have to
> handle two different read modes in Cygwin is already bad enough.  I'm
> not really looking forward to add another read mode for which I don't
> see an obvious need.  You don't really expect lots of upstream devs to
> happily pick up on such a change with two new O_ open flags *just* for
> Cygwin, do you?

Agreed, nope.

It turns out that setmode(fd, 0) is what I'm looking for,
and there is no need to change anything in the API.

So rather than not using setmode(), we should tell upstream to not use
O_TEXT but zero instead, which might be easier to accept for them.

> You have two modes for input and three for output:
> 
> - input O_BINARY  -> only \n
> - input O_TEXT    -> \n and \r\n
> 
> - output 0        -> generates \n or \r\n depending on mount mode
> - output O_BINARY -> generates \n
> - output O_TEXT   -> generates \r\n

Erm, even for input there is mode 0: strips \r depending on mount mode.
This actually is without using setmode() at all.
Shouldn't the default (mode 0) behave like O_TEXT for input?

Thanks!
/haubi/

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