Re: textmode for stdout, what is "correct" now?

[Michael Haubenwallner <michael dot haubenwallner at ssi-schaefer dot com>]

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