public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* A little improvement for setmode(fd, 0)?
@ 2019-02-22 15:54 Michael Haubenwallner
  2019-02-22 22:16 ` Corinna Vinschen
  0 siblings, 1 reply; 2+ messages in thread
From: Michael Haubenwallner @ 2019-02-22 15:54 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 2718 bytes --]

Hi Corinna,

sorry to be annoying, but I'm still not completely happy with the
setmode(fd, 0) API yet:

Using setmode(fd, 0), beyond "I am aware that not everything is binary",
an application's point of view when ported to Cygwin is something like:
"For this (maybe bidirectional) file descriptor, wherever the user does
connect it to (stream, binary mounted fs, text mounted fs, ...), I do
*not need* to transfer binary content.  That is, to stay as POSIXy as
possible, for line breaks I do not want to handle any \r in my text."

Hence, read() should not deliver the \r when reading any line break, and
write(\n) should add the \r only when the target does require that (like
the file on a text mounted fs).

As there is no clean way to ignore \r for reads without forcing \r for
writes, right now a complete-as-possible patch for openssl may look like:
https://gitweb.gentoo.org/repo/proj/prefix.git/tree/dev-libs/openssl/files/openssl-1.1.1a-cygwin-binmode.patch?id=05d897568b21446657001a51660e9a25172474f2

But there still is the difference between readonly and read+write.

Attached is a test script for a collected overview of the behaviour
differences when applications use the setmode() API call.

$ ./setmodetest.sh
Testing behaviour of various setmode() arguments...
---------+--------------------------+--------------------------+
perform: |   read from 0d0a input   |   write the single 0a    |
filesys: | stream | binary |  text  | stream | binary |  text  |
---------+--------+--------+--------+--------+--------+--------+
 default |   0d0a |   0d0a |     0a |     0a |     0a |   0d0a |
O_BINARY |   0d0a |   0d0a |   0d0a |     0a |     0a |     0a |
  0      |   0d0a |   0d0a |     0a |     0a |     0a |   0d0a |
O_TEXT   |     0a |     0a |     0a |   0d0a |   0d0a |   0d0a |
---------+--------+--------+--------+--------+--------+--------+

So what I would like to see is a behaviour like this:
---------+--------------------------+--------------------------+
perform: |   read from 0d0a input   |   write the single 0a    |
filesys: | stream | binary |  text  | stream | binary |  text  |
---------+--------+--------+--------+--------+--------+--------+
  0 ?    |     0a |     0a |     0a |     0a |     0a |   0d0a |
---------+--------+--------+--------+--------+--------+--------+

Even if that would mean that setmode(fd, 0) does not switch back to default
behaviour any more.  But then, isn't the default behaviour designed for
applications that do not use (are unaware of) the setmode() API at all?

Thoughts?

For completion:
$ ./setmodetest.sh --trace
does create the list of commands being executed.

$ ./setmodetest.sh --with-fopen
does use the FILE handle API

Thanks a lot!
/haubi/

[-- Attachment #2: setmodetest.sh --]
[-- Type: application/x-shellscript, Size: 9402 bytes --]

[-- Attachment #3: Type: text/plain, Size: 219 bytes --]


--
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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: A little improvement for setmode(fd, 0)?
  2019-02-22 15:54 A little improvement for setmode(fd, 0)? Michael Haubenwallner
@ 2019-02-22 22:16 ` Corinna Vinschen
  0 siblings, 0 replies; 2+ messages in thread
From: Corinna Vinschen @ 2019-02-22 22:16 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Feb 22 16:43, Michael Haubenwallner wrote:
> Hi Corinna,
> 
> sorry to be annoying, but I'm still not completely happy with the
> setmode(fd, 0) API yet:
> 
> Using setmode(fd, 0), beyond "I am aware that not everything is binary",
> an application's point of view when ported to Cygwin is something like:
> "For this (maybe bidirectional) file descriptor, wherever the user does
> connect it to (stream, binary mounted fs, text mounted fs, ...), I do
> *not need* to transfer binary content.  That is, to stay as POSIXy as
> possible, for line breaks I do not want to handle any \r in my text."
> 
> Hence, read() should not deliver the \r when reading any line break, and
> write(\n) should add the \r only when the target does require that (like
> the file on a text mounted fs).
> 
> As there is no clean way to ignore \r for reads without forcing \r for
> writes,

This isn't true.  Just link your application with -ltextreadmode

Why is that not sufficient?



> right now a complete-as-possible patch for openssl may look like:
> https://gitweb.gentoo.org/repo/proj/prefix.git/tree/dev-libs/openssl/files/openssl-1.1.1a-cygwin-binmode.patch?id=05d897568b21446657001a51660e9a25172474f2

My patch has already gone upstream.  It just does not enforce
text mode on write, ever.

> But there still is the difference between readonly and read+write.

O_RDWR is a special case.  In general you never want to have different
read and write modes on the same file, otherwise you're bound to schred
the file to pieces.

Therefore, let's stick to O_BINARY mode by default, and use O_TEXT
only in border case.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-02-22 15:54 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-22 15:54 A little improvement for setmode(fd, 0)? Michael Haubenwallner
2019-02-22 22:16 ` Corinna Vinschen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).