Mail Archives: cygwin/2019/02/18/08:16:15
--f6M9UaX53EEZorp0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 o=
ff,
> >> 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.
> >=20
> > Bottom line:
> >=20
> > - 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).
>=20
> No, O_TEXT is neither equal to O_BINARY nor to O_DOSTEXT - it's something
> in between. My first ideas are either (O_BINARY|O_DOSTEXT) or another bi=
t.
>=20
> > - Make O_DOSTEXT equivalent to the former O_TEXT.
>=20
> Yes.
>=20
> > Result: we use binary mode even with tools explicitely specifying O_TEX=
T.
>=20
> No, not binary mode. It's text mode with \r being allowed rather than for=
ced.
You lost me here. Reading in O_TEXT mode already does not require \r\n,
it just allows \r\n as well as \n as line ending. Given that, I don't
see a reason to add O_DOSTEXT. What would it do differently? Enforcing
\r\n line endings in input?
> Just stumbled over the distinction between readmode and writemode:
> What's up with that?
automode.o and textreadmode.o are just conveniences. If you link an
application with them, descriptors the app opened O_RDONLY are in O_TEXT
mode automatically, and descriptors opened O_WRONLY are O_BINARY
(automode.o) or depending on mount mode (textreadmode.o) automatically.
You can't mix O_TEXT and O_BINARY on O_RDWR descriptors.
> Unless binary mode, reading always could be done in dostext mode.
> Here the default is to link without them, and the opposite of binmode.c
> is to not use anything, hence the text*mode should be O_DOSTEXT.
I fail to scan this paragraph, sorry. Are you still taking about
the *mode.c files?
> > - 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?
> >=20
> > 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.
>=20
> Exactly. And for the check:
> For dostext mode: ifdef O_DOSTEXT: use O_DOSTEXT, otherways use O_TEXT.
> For cygtext mode: ifdef O_DOSTEXT: use O_TEXT, otherways avoid setmode.
>=20
> > 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.
>=20
> Yes, but I do expect this in corner cases only, with unix2dos/dos2unix as
> the specific example.
>=20
> OTOH, with setmode(fd, 0) coming to my mind: If that would denote the def=
ault
> (=3Dcygwin text) mode, I can imagine we may convince (openssl) developers=
to use
> zero instead of O_TEXT, and everything could be fine without any Cygwin c=
hange.
>=20
> Heck, this would feel like most obvious - even API wise, no?
>=20
> Then we may want to add O_NOBINARY defined to zero as the only Cygwin cha=
nge.
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?
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
I don't see how O_DOSTEXT comes into this picture. There's no reason
for an enforcing \r\n input mode, and in output mode it won't differ
from O_TEXT, unless you define O_TEXT to be the same as O_BINARY in
future. We can also already control per-app default settings by linking
apps against one of the *mode.o files.
What do we really gain by inventing two new Cygwin-only open flags,
other than restarting the old O_TEXT problems with upstream devs?
Corinna
--=20
Corinna Vinschen
Cygwin Maintainer
--f6M9UaX53EEZorp0
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlxqr+IACgkQ9TYGna5E
T6BYBw/+PC0ZinpGAmJ1RWiFp9nAIufXuDV83t2bGHm2ZcEw4/1+b2sJSO1gCGgU
HF1lapp9TxklX8V/80LKw7bOLl3tob0h44b5/6hQcMmJXRZ3x7GXzqIWAuO+6H+s
qb9IwtrtuSZfvle3p1+Qq0ZC/JB90ciMywIb8P3LtwX8OIaDmFvP030EYndv2Um2
FZNISXwHQjwN7ub07AMmd5PHUm+ph+3sq5kn4WNh68am7WbS4B1lci4cOKD6mP8D
jFwz5fDAjYD8nEPC/BmYxE+/s23mYfIxcqAISJejfQaBHlTBkEYvp3dLZoKzubEt
mmOqbXB4XGntiCiaxcL3RuJ6gYaP0Rko3tZFDbn/dms/CpCKQlgQuakeHtQjdn3V
vg8C4eDzSYiyvJpIVqxNN1KKdM6fy9ZjFYr5/cuODtFT5y5XGpMRFKP81PwWsB6u
xf4Vzq1APTmWHuVYrSGYUKCO2rMXSsdcjQEXiZO7s7jwoPneC0C44AUTzEqj2bBA
dkt95uDc4tmPzQKmg3ZFmQPAkPFFmfo/FTQdQfTjVF8wSoDsgbjGDSnZjBeF5sUY
Fu5Ke6C5JD+GVOW27PEMIMier4mL0F4ILxUMZft4i1zXPWpWJ0SsHy/DrzIkZ88N
esjOUVkYHrfOcia6Fp9MFbGmKmLef6mBnz3j+CrwVKss+MU3SOk=
=BcBg
-----END PGP SIGNATURE-----
--f6M9UaX53EEZorp0--
- Raw text -