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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=DOEosm735BGHYehEWZu2bo4KiHoA4rtSl6dhB8pEVCYy+xO6jpXHy
	1fhqaY+4Sp4SuYr+QcUVQqjbgHdPqrb4Y8zD0Yp8lBWv4CB9av/khQW1Vn5s+cBB
	/qTKl4/dY1vFqbPvA9gL6CNBmWJuCgmMQEgB1wiI0pzMvmNdtnoUkA=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=Q6Hr5cyvGBUJvxdz4rrlZ4wp7wM=; b=Ks8iLIHTOW7mV24Hz8udJgEmwzQ+
	p4E5yLHaaWhpfxqFFN5guYmZNvvPFe3nsZChNvYYKOlWBcsKFU49aVGso9Un6BDl
	MnfsAFN6KPOF/45DiLwPhn+7FcNhPPHXB/GqRTf9ce49Gogx9qiimj+vLmp6V0YW
	vl2oHPm9FYzj7EA=
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=-100.9 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=formatted, Hx-languages-length:2407, bottom, H*F:D*cygwin.com
X-HELO: mout.kundenserver.de
Date: Mon, 18 Feb 2019 11:26:50 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: textmode for stdout, what is "correct" now?
Message-ID: <20190218102650.GW4256@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="vru7fAags9pVPvn5"
Content-Disposition: inline
In-Reply-To: <380fcd6e-cbe1-ebe4-c13f-a8d911c148ac@ssi-schaefer.com>
User-Agent: Mutt/1.10.1 (2018-07-13)

--vru7fAags9pVPvn5
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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.
>=20
> 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?
>=20
> 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."
>=20
> 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).

- Make O_DOSTEXT equivalent to the former O_TEXT.

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

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

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

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


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--vru7fAags9pVPvn5
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlxqiGoACgkQ9TYGna5E
T6DGKg//SHHmljWK3u0uLe6m5q9xIZCdk8f8bmf6CxTU4AM6fikFwp4/jpFIHKkP
ODvAgzpeHQuwcpKdjR+Db4I4VVCxerK86w/WKtfUMBCw7wf/0xOKpFbtPk1WYzkX
s1g3fUpiVSfGpVm35MdtqIW+EIchce382wbV6QhxG5gfFklsKPPzJqZF/q8Cxtlw
e24ea7v/vva/l1Ew6XZNnvBNfLulv3PcRdkVwJIlmlZHbZiZopGLoLOsUrk+LKks
wwrHSy22fFTfNvrR8PqEMgDZ59J1tesIVsT7wyLr1t4zdy16H7ZfJtMWHYrLxS6z
9b6Aoa2oMqUwSfWEKkMg+nEUblCPnF5dnxsCWCv20nbWXaER3VYHM8XseqxZybvr
IXJWn8kRFDzkRpPVrm4t9TyTQkWg0m5PSuUrfDd+Xal7TEd2m79esCFbc2UwQPJK
9cL7rnIHZ7Pw1a2sTlaxTOTfiVrfR0t2hkw/ZlSntBCywv/DLmUoKHLT4g7DkCtm
44Nh6x/4uKKy3B0ipYSLDPKL1yAfEaNHDGPtpWSgHJml9FjaiUL66saXZuPpKh/6
BYaXGMWm5OZXKDqzaLwsi0sPC28V6KVy7ZulxFK/TauNNFbIp/mMHonbwttjwWwL
ekk/B+hbZXLLY2oG7w4PZoep/+7rqel+TNy5dHdgHP9hNmpeWxQ=
=XKlN
-----END PGP SIGNATURE-----

--vru7fAags9pVPvn5--