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=HrUadZSYA17CBoys
	sW7Db3eJK/c2mFVcpWZXaBtoTNFLPDZdbRH/dQS4GY5vIl+ut2oDunKRRw4ntwl7
	t5NoAVlyLc/VLB5UIBUxqQWHrMKo0dwFYkqnMcW6r2UikPQR/6mjwc0oJiJ9eP2U
	dIiLNy6Egbg154GYRBUB6K7HOXU=
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=qx/xgxVhLyc19PbtS4YdMd
	ADdxg=; b=IVOvsQLQv11ATKoQ/PqsoRoYWlxLCL8HsRDo4sqnMz4xmmSj1mAqQm
	Ma0cYDYR5bFwdXNQxFwBPGygwL2ZGX8dn9/vmTzUp0e0PSkpUfGIcbMNDw3UoqKs
	OPKXeY8ZljrRfHDMZQJI9wSytPxPDDVl+IQmXkwhT/6GlugTFnc4I=
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=HX-Envelope-From:sk:michael, H*RU:sk:michael, troubles, Hx-spam-relays-external:sk:michael
X-HELO:	atfriesa01.ssi-schaefer.com
Subject:	Re: textmode for stdout, what is "correct" now?
References:	<739ed5ce-6902-d702-e152-65dc2c1da667 AT ssi-schaefer DOT com> <20190214162002 DOT GA4950 AT calimero DOT vinschen DOT de> <6aa280c2-4769-0772-91d9-c73a3a3d9680 AT ssi-schaefer DOT com> <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>
From:	Michael Haubenwallner <michael DOT haubenwallner AT ssi-schaefer DOT com>
To:	cygwin AT cygwin DOT com
Message-ID:	<6d02258d-115d-135c-1404-1b02eec34045@ssi-schaefer.com>
Date:	Fri, 15 Feb 2019 19:07:51 +0100
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version:	1.0
In-Reply-To:	<20190215124844.GE2702@calimero.vinschen.de>

On 2/15/19 1:48 PM, Corinna Vinschen wrote:
> On Feb 15 13:03, Michael Haubenwallner wrote:
>> On 2/15/19 11:22 AM, Corinna Vinschen wrote:
>>> On Feb 15 08:56, Michael Haubenwallner wrote:
>>>> On 2/14/19 5:20 PM, Corinna Vinschen wrote:
>>>>> On Feb 14 16:23, Michael Haubenwallner wrote:
>>>>>> Hi,
>>>>>> [SNIP]
>>>> Down the line in their BIO module they do use setmode(fd, O_TEXT),
>>>> which is the one that does introduce the \r, as far as I know.
>>>
>>> This one is not so nice.  Somebody should tell upstream we only
>>> want explicit O_BINARY these days, but no explicit O_TEXT.

To me it sounds strange to use the one but not the other:

If we don't want O_TEXT at all, isn't O_BINARY obsolete as well,
so the advise should be to use neither - just like real *nix?

A consequence then might be to deprecate (or even remove) them
from the public API header files.

>> Is this correct even for situations where the cygwin1.dll is used
>> outside the Cygwin distribution, like git-bash, MSYS or similar,
> 
> This is OpenSSL, not the Cygwin DLL.

Actually I meant executables linked against the Cygwin DLL being
executed by non-Cygwin (native Win32) programs.

>> where cygwin-based executables eventually are used from within some
>> CMD or PowerShell script? Or should they use unix2dos/dos2unix then?
> 
> Only if the \r is really required.  Typically it isn't.

Ok then.

>> OTOH, would it make sense to ignore the O_TEXT flag in cygwin1.dll?
> 
> That's an interesting idea.  The O_TEXT flag is already ignored in a lot
> of cases, e.g. for pipes.  Only when opening files does it have an
> effect, mostly.  I'm not sure we should really switch it off.  Maybe we
> can consider a CYGWIN env var setting at one point.

I've thought of the CYGWIN env var too whether to ignore O_TEXT, but the
more I think of it, the more I can think of multiple troubles as well...

>>>> The backtrace in openssl-1.1.1a in this use case is:
>>>> [...]
>>>>>> Question now is: These days, what is the correct way to handle this?
>>>
>>> Telling upstream not to use O_TEXT on Cygwin in the first place, I think.
>>
>> I can do that, but if I were an upstream developer I would ask questions
>> like above...
> 
> I sent a patch upstream and questions got asked.  But this is not
> a native openssl lib, this is *Cygwin's* openssl lib, and it should
> behave like a Cygwin lib.

Agreed.

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 -