textmode for stdout, what is "correct" now?

[Michael Haubenwallner]

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