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
