From: mutazilah@gmail.com   
      
   On 21/02/24 01:55, Lew Pitcher wrote:   
   > On Tue, 20 Feb 2024 22:25:05 +0800, Paul Edwards wrote:   
   >   
   >> On 20/02/24 22:14, Lew Pitcher wrote:   
   >>> On Tue, 20 Feb 2024 14:51:15 +0800, Paul Edwards wrote:   
   >>>   
   >>>> Hi.   
   >>>>   
   >>>> Cygwin has an O_TEXT on the open() call to let   
   >>>> "the OS layer" (can be quibbled) that the file   
   >>>> is being opened in text mode. And as such, it   
   >>>> gives that layer an opportunity to insert CRs.   
   >>> [snip]   
   >>>> I'd like to add an O_TEXT flag to Linux.[snip]   
   >>>> Any suggestions?   
   >>>   
   >>> Yes, one. Dont.   
   >>>   
   >>> Microsoft Windows (on top of which Cygwin must run) makes a low-level   
   >>> distinction between "binary" files and "text" files. I believe it is   
   >>> because Windows guarantees (or must guarantee) certain data   
   >>> transformations on text that do not apply to other forms of data.   
   >>> (I.e. translating  sequences into C newline characters, etc)   
   >>>   
   >>> HOWEVER, Linux (or, /any/ Unix) makes NO distinction between text   
   >>> and binary data, neither in the standard I/O library, nor in the OS   
   >>> itself.   
   >>>   
   >>> You are effectively asking that Linux /NOW/ make such a distinction,   
   >>> even if only to ignore the O_TEXT flag that you ask for.   
   >>   
   >> The C library that most people use already has   
   >> that distinction - and it is indeed ignored.   
   >> Works perfectly fine.   
   >   
   > Lets take an accounting...   
   >   
   > 1) POSIX open() does not make any distinction between "text" and "binary"   
   >    files   
   >   
   > 2) Standard C / POSIX fopen() /does/ make a distinction between "text"   
   >    and "binary" files. POSIX issues a caveat regarding the mode   
   >    parameter that "The character 'b' shall have no effect, but is allowed   
   >    for ISO C standard conformance.", referring to the mode character "b"   
   >    specified by the ISO C standard as indicating that the file should be   
   >    opened for "binary" I/O, rather than the default "text" I/O.   
   >   
   > 3) You specifically reference the open() call, not the fopen() call.   
   >   
   > So, you ask that the open() call, a call that, under Linux and other   
   > POSIX-compatible operating systems, makes no distinction between binary   
   > and text files, now recognize a flag indicating that the open() should   
   > act apon a text file.   
   >   
   > That leaves the Linux kernel developers with a choice to make: either   
   > a) accept your request and add an O_TEXT flag that conditions the I/O   
   >    for text data, or   
   > b) accept your request and add an O_TEXT flag that does nothing, or   
   > c) ignore or deny your request   
   >   
   > Choice (a) would drastically change the behaviour of the open()   
   > call, and any existing code that uses open() to access a text file would   
   > have to change to specify the O_TEXT flag. I believe that this would   
   > be a no-starter, even if the default for O_TEXT would leave behaviour   
   > as it currently is.   
   >   
   > Choice (b) is ... useless. It recognizes a non-issue, and does nothing.   
   > It would be a header change that reserves a flag that would be ignored   
   > by everyone.   
      
   Almost everyone.   
      
   PDOS/386 would use it.   
      
   > I believe that the maintainers would simply veto this   
   > as being a change that makes no change.   
   >   
   > So, choice (c) is my bet. The maintainers simply ignore (if they want   
   > to be polite) or deny your proposal.   
      
   Sure. Hence my question.   
      
   I'll take a random flag myself. Any suggestions?   
      
   >>> It ain't gonna fly. Such a flag would invalidate /decades/ worth of   
   >>> Unix/Linux code, and /not/ provide any functionality either to   
   >>> the OS layer, the stdio library layer, or the application code layer.   
   >>   
   >> Sorry - what is being invalidated? Can you give an   
   >> example?   
   >   
   > Today, I can   
   >   open("/etc/passwd",O_RDONLY)   
   > and read text from the text file /etc/passwd. I can   
   > also   
   >   open("/sbin/init",O_RDONLY)   
   > and read binary data from the binary file /sbin/init   
   >   
   > If I understand correctly, you propose that code now   
   > must   
   >   open("/etc/passwd",O_RDONLY | O_TEXT)   
   > to read text from the text file /etc/passwd.   
   >   
   > What would happen if, under your proposal, code still   
   > executed   
   >   open("/etc/passwd",O_RDONLY)   
   > ? Could the code still read() text data, or would the   
   > open() fail on something like EACCESS or EINVAL or   
   > EOPNOTSUPP? What /would/ the consequences be of setting   
   > O_TEXT?   
   >   
   > Of course, if you answer that, under a POSIX-like system,   
   > there would be /no/ consequences to O_TEXT, then you   
   > have presented choice (b), a change that changes nothing.   
      
   Correct. Nothing is invalidated.   
      
   It is only when run on a Windows-like system that   
   something happens.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)