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=rO5oIyC/7h75U9L7
	6CR3DqgfM92KxOhnfgt7vU7rrzQDO4VnUsRowkczpdUj0sDZmMsU9CEOMQVGsz0p
	Q2aWC1B/FruMrp03vbxl9lshZnyJ82f5xbgSvJYnycJ2QPgBl44ISA/TDBaiYJhb
	aALJTsiRt+Uj3pYh8IGVuy/0ayQ=
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=KJ6fgftyVc/UtYM0Ef76f6
	m0wl0=; b=WkrtDQTI6IFajl041xLTvRPE1n7TElzpc2T17ZI8q06DNciRepEZdC
	TmPbh/kULUflWfcjp0ObnElkhK8Lv1ZgvQFbxFBGJ6+iCl9jFs8JodRnHQWDkIvJ
	HYQ4mFZqA1Nf5cjqqQe1MHuioGrryGjsSvZIHmCH0yVIUFmTU4XXQ=
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=ham version=3.3.2 spammy=Unless
X-HELO: atfriesa01.ssi-schaefer.com
Subject: Re: textmode for stdout, what is "correct" now?
References: <20190215102251 DOT GA2702 AT calimero DOT vinschen DOT de> <f7345109-5b22-a342-df1e-940e236c2397 AT ssi-schaefer DOT com> <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>
From: Michael Haubenwallner <michael DOT haubenwallner AT ssi-schaefer DOT com>
To: cygwin AT cygwin DOT com
Openpgp: preference=signencrypt
Message-ID: <696f5a12-ad45-c3d9-715b-bd68b3f8d14c@ssi-schaefer.com>
Date: Mon, 18 Feb 2019 12:47:59 +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: <20190218102650.GW4256@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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.
> 
> Bottom line:
> 
> - Make O_TEXT equivalent to O_BINARY on the API level so Cygwin
>   actually uses binary mode on open(O_TEXT) and setmode(O_TEXT).

No, O_TEXT is neither equal to O_BINARY nor to O_DOSTEXT - it's something
in between.  My first ideas are either (O_BINARY|O_DOSTEXT) or another bit.

> - Make O_DOSTEXT equivalent to the former O_TEXT.

Yes.

> Result: we use binary mode even with tools explicitely specifying O_TEXT.

No, not binary mode. It's text mode with \r being allowed rather than forced.

> - How do you handle fopen modes "wt", "rt", etc, then?

This API feels a little different, because it does allow for with "b" and
without "b", as well as with "t" and without "t", so "t" should translate
to O_DOSTEXT IMO.

While talking about it: What will setmode(fd, 0) do?

> - What about automode.c, binmode.c, textmode.c, textreadmode.c?

Just stumbled over the distinction between readmode and writemode:
What's up with that?
Unless binary mode, reading always could be done in dostext mode.
Here the default is to link without them, and the opposite of binmode.c
is to not use anything, hence the text*mode should be O_DOSTEXT.

> - How do you avoid breakage of existing tools which have been written to
>   work explicitely with certain DOS formatted text file and use O_TEXT
>   for that?
> 
> The answer to the last one could be using a new version check like the
> ones already in include/cygwin/version.h.  Existing tools and libs keep
> the current behaviour.  Only newly built binaries get the new behaviour.

Exactly. And for the check:
For dostext mode: ifdef O_DOSTEXT: use O_DOSTEXT, otherways use O_TEXT.
For cygtext mode: ifdef O_DOSTEXT: use O_TEXT, otherways avoid setmode.

> However, this still may result in breakage if the developer isn't aware
> of this subtil change.  As much as I hate O_TEXT mode, there's a
> pretty basic expectation how this is supposed to work.

Yes, but I do expect this in corner cases only, with unix2dos/dos2unix as
the specific example.

OTOH, with setmode(fd, 0) coming to my mind: If that would denote the default
(=cygwin text) mode, I can imagine we may convince (openssl) developers to use
zero instead of O_TEXT, and everything could be fine without any Cygwin change.

Heck, this would feel like most obvious - even API wise, no?

Then we may want to add O_NOBINARY defined to zero as the only Cygwin change.

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